SSR Knowleadge Sharing all-in-one.pptx

SSR Knowledge Transfer all-in-one

Created by Kevin Wang N in 2014 June

Kevin Wang N | Ericsson Internal | © Ericsson AB 2013 | Page 2

AgendaSSR Hardware Overview

SSR RPSW Overview

SSR ALSW Overview

SSR SW Card Overview

SSR Line Card Overview

SSR New Feature in R1

SSR NEW Feature in 12B

SSR NEW Feature in 13A

SSR NEW Feature in 13B

SSR NEW Feature in 14A

SSR Fabric Overview

SSR IPOS Software

SSR&SE config differences

SSR Troubleshooting


SSR Hardware Overview


SSR Family

*HW ready/Initial

SSR 8004 SSR 8010 SSR 8020

Slots 4 10 20

Port Density160x1G, 40x10G, 8x40G, 4 x

100G400x1G, 100x10G, 20x40G,

10x 100G800x1G, 200x10G, 40x40G,

20x100G

Backplane Capacity 3.2 Tbps 8 Tbps 16 Tbps

Initial Simplex Capacity 0.8 Tbps 2 Tbps 4 Tbps

Full Duplex Slot Capacity* 400/100 Gbps 400/100 Gbps 400/100 Gbps

Height (RU) 8 21 38

Units/ 7 ft rack 4 2 1

Initial Power ~4 kW ~7 kW ~11 kW


How Do we get to 1TB?

Petra+FE60032 * @5.75Gbps

100G

Spider2/NP +2*FE160064 * @11.5Gbps

400G

Spider3 / NP+2*FE320064 * @23Gbps

1TB

Gen 1 Gen 2 Gen 3

10x10G Vogon / Valkyrie

16x10G Spider 1x100G Neptune 40x10G Hydra 4x100G Triton

Optics XFP Gray/Tunable/OTN SFP+ Gray/Tunable

CFP Gray/tunable/OTN

SFP+ Gray/Tunable CFP Gray/Tunable/OTNCFP2 Gray

Line cards

Switch fabric

FD Slot capacity


Smart Services Router ChassisSSR 8020

Power Entry Modules

RP, Alarm &SwitchFabric

Fans

Air Outlets

Fans

Line Cards

Height of 38 RU (66.5”)

20 I/O slots with up to 40 SFPs per card

2 RP switch fabric cards

2 Alarm fabric cards

4 Switch fabric

8 slots for power supplies (DC only power source)

Rear external power cabling

Bottom-front to rear-top airflow

2 fan trays – six fans per tray

Cable management above fan trays

RP 1+1 redundancy

Alarm card 1+1 redundancy

Load shared switch fabric redundancy Air InletAir Inlet


Smart Services Router ChassisSSR 8010

Power Entry Modules

RP, Alarm &SwitchFabric

Fans

Air Outlets

Fans

Line Cards

Height of 21 RU (36.8”)

20 I/O slots with up to 40 SFPs per card

2 RP switch fabric cards

2 Alarm fabric cards

6 slots for power supplies (DC only power source)

Rear external power cabling

Bottom-front to rear-top airflow

2 fan trays – six fans per tray

Cable management above fan trays

RP 1+1 redundancy

Alarm card 1+1 redundancy

Load shared switch fabric redundancy Air Inlet


SSR 8020 Cards

Smart Services RouterSSR Cards

Control CardsHalf Height

LINE CARDSFull HeightLine CardsFull Height

SMART SERVICE CARDFull Height

Smart Service Cards

Full Height


Ericsson SSR 8020Line, Service and Control cards

8x Control cards-Switch Fabric

-Alarm-Route Processor

20x Line/Service cards-Line cards

40x1G 10x10G

2x40G, 1x100G-Smart Services Cards

EPG, BNG, CDN, Service Management


Smart Services RouterSSR Route Processor / Switch Cards

› Total of 3 cards– SW: Switch Fabric– ALSW: Switch Fabric & Alarm– RPSW: Switch Fabric & Route Processor

› Switch Fabric is distributed across all control cards

› Non-blocking fabric architecture› Graceful degradation in case of control card

failure– SSR 8020: 6+2 redundancy– SSR 8010 / 8004: 3+1 redundancy

SW


Smart Services RouterSSR Control Cards (Generation 1)

› SW– Switch Fabric Module

Switch Fabric

Switch Fabric Route Processor› RPSW

– Switch Fabric & Route Processor Module

› ALSWT– Switch Fabric, Alarm and Timing Module

Timing

SyncE

1588

Stratum 3E

E1/T1

Switch Fabric

Alarm

Logic


Smart Services RouterSSR Control Cards (Generation 2)

Switch Fabric

Route Processor

Timing

SyncE

1588

Stratum 3E

E1/T1

Switch Fabric

Switch Fabric

Switch Fabric

Switch Fabric

Switch Fabric

Alarm

Logic

› SW– Switch Fabric Module

› RPSW– Switch Fabric & Route Processor Module

› ALSWT– Switch Fabric, Alarm and Timing Module


SmartEdge Control Plane Architecture

I/O

NetBSD

SCL

Line Cards (x 12)

XC Cards (x 2)

I/O FPGAIPPA

EPPA PMA

to PMAs on other cards

I/O FPGAIPPA

EPPA PMAI/OFPGA

IPPA

EPPAPMA

I/OFPGAIPPA

EPPAPMA

SCL SCL

SCL SCL

SCL

VxWorks

NetBSD

VxWorks

I/O

› SmartEdge System – Line Cards

› Use IPPA and EPPA structure – XC Cards

› Dual OS (NetBSD and VxWorks) each running on a PPC processor

› Analogy to SSR System – Line Cards

› PPA3LP and Spider has the same structure › NP-based line cards (shown earlier) has bidirectional packet handling

capability – RPSW

› Hosts Linux OS on a Intel processor


SSR Control Plane Architecture

10 GE

RPSW

4xGE

Jasper Forest

10 GE

RPSW

4xGE

Jasper Forest

GESwitch

ALSWGESwitch

ALSW

FAPNPU

LC LP

FAPNPU

LC LP

FAP NPU

LCLP

FAP NPU

LCLP

› Line Card Local Processor – NPU punt control packets to LP

› Control packets such as route decisions and etc. › LP schedule and queue control packets

– LP hosts forward abstraction layer (FABL) and adaptation layer daemon (ALD)

› FABL provides PI interface and enables PI code development › ALD implements platform-specific control features

› SWRP Route Processor – Intel Jasper Forest Processor

› Hosts Linux OS and SEOS software › Perform route computation and communication

› Control Path– Dedicated Gigabit Ethernet Control Plane Switching

› GE path: LC to/from SWAL› 10GE path: SWAL to/from SWRP › Managed via Inter-Process Communication (IPC)


SSR 8020 Fabric


SSR 8020 Airflow

CardsRear of ChassisFront of Chassis

Fan 1

Fan 2

Chassis Intake

PEM Intake PEM Exhaust

Chassis Exhaust


Smart services RouterPower Subsystem › Power Modules (-48VDC)

– 6+2 Redundancy– Active Load Sharing – Front field replaceable – Dual rear input feeds– Input: 2400W max– Output: 2100W max

› Internal Power Distribution– Single Load Zone– Card Level Fuse, Filter & IBV– Card Level Digital POLs

› Green footprint– 480 Watts slot capacity– 330 Watts line Card at FCS P

OW

ER

BU

S

PM1Primary Feed

Secondary Feed

Primary Feed

PM1Primary Feed

Secondary Feed

Primary Feed

PM1Primary Feed

Secondary Feed

Primary Feed

PM1Primary Feed

Secondary Feed

Primary Feed

PM1Primary Feed

Secondary Feed

Primary Feed

PM1Primary Feed

Secondary Feed

Primary Feed

PM1Primary Feed

Secondary Feed

Primary Feed

PM1Primary Feed

Secondary Feed

Primary Feed

RPSW (2)

ALSW (2)

SW (2)

Fan Tray (2)

Line Card 1

Line Card 2

Line Card 20


Ericsson SSR 8020Line, Service and Control cards

8x Control cards-Switch Fabric

-Alarm-Route Processor

20x Line/Service cards-Line cards

40x1G 10x10G

2x40G / 1x100G 40G BNG

-Smart Services Cards


SSR RPSW Overview


› Control processor and switch fabric› Dual image boot capability› RPSW front panel

– 10/100/1000Base-T RJ45 management interface– Console port / Cisco style RJ-45– One USB Type A connector for slave storage device mounting

› Intel x86 Jasper Forest processor (Intel’s latest Server Processor)– Native Quad Core, with 32K L1 and 256K L2 case per core.– Provide 8 Mb of shared L3 cache.– Three Local DDR3 memory Channels

› Storage– Internal USB (x2) – 16GB each – External USB pluggable

› 24 GB DDR3 RAM › Control plane interface

– 2 x 10GE to control plane switch on ALSW modules– 2 x 1 GigE interfaces between RPSW modules

Route Processor Switch Card


SSR Memory InfoSWRP today has two physical parts (chips) that make up the 32G eUSB. Each part is 16GB. Following diagram shows how these memories are partitioned

/Var

Logs

Syslogs

Application logs

Kernel crash files

Core Dumps

P01 4GB

P02 4GB

FLASH 8GB

16G16G

Kernel(6MB) + Root FS(105MB) + IPOS Application/Libs (~1GB)

Kernel(6MB) + Root FS(105MB) + IPOS Applications/Libs(~1GB)

Customer Data and Configuration files storage


Route Processor Switch Card

Intel Jasper Forest +North Bridge

QuadPCIe GigEIntel 82580

Dual PCIe10GbE

Intel 82599

PLXPCIe brdg

DDR3

PECI

ESI

RJ45

PCIe x 4Gen 1

PCIe x 4Gen 2

PCIe x 4Gen 2

FP USB

eUSB BIOS

US

B

SP

I

LOGIC

FS

BACK PLANE

PCIeGen 1

CP

U B

us

I2C

BackplaneSerdes

Intel Ibex PeakSouth Bridge

PCI

LEDs

10/100/1000 BASE-T Management

RJ45

RS232 RS232

HDR

Con

sole

UA

RT

Deb

ug

UA

RT

NVRAMRTC

512KB

Card Management Bus

1000

Bas

e-B

X R

P

1000

Bas

e-B

X R

P

10G

Bas

e-K

R –

AL0

10G

Bas

e-K

R –

AL1

PC

Ie x

1 –

Gen

1 x

7 to

RP

/AL/

SW

SwitchFabricControl

SystemControl Plane

Inter SWRPCommunications

SelectionControl Bus


SSR Control Plane Interfaces

Control Plane ApplicationGbE Control Plane Ethernet Control plane is a high speed packet based control plane

used for communication between RPSWs and LCs

Switch Fabric Control (PCIe) Used by RPSW to control all switch fabric card resources

Card Management Bus (CMB) Used by RPSW to control and distribute information to other elements in the chassis...ALSW, SW and LCs.

Selection Control Bus (SCB) Used by ALSW to determine RPSW master and to communicate that information to all switch cards

Timing Control Bus (TCB) Used by ALSW to provide reference & epoch clocks Also used to convey RPSW mastership to each line cards.

Common Equipment Control (I2C Bus) Used by active RPSW card to control common equipment such as Fan Trays, Power Entry Modules (PEMs) and Chassis EEPROMs.


GbE Control Plane

› Communication channel between RPs and Line cards

› 1+1 Redundancy› GigE switching on the ALSW cards› Dual control plane mechanism

– Fabric – Dedicated control bus

Switch Processor

Card

Switch Processor

Card

Line Card

Line Card

Line Card

Line Card

AlarmCard

AlarmCard

10G

1G


RPSW Mastership Selection› RPSW mastership selection process – Four phase Determination of a RPSW mastership capability

This is accomplished via a software controlled test – a set of internal RPSW card test.

Mastership capability is declared to both ALSW cards via PCIe memory space writes on ALSW cards. ALSW cards will start to maintain a watchdog timer.

Determination of a primary ALSW to make the mastership selectionA negotiation process is used between ALSW to determine primary ALSW. The process involves exchanging status vectors and comparing the received vector with its own to determine which ALSW is capable to be primary ALSW.


RPSW Mastership Selection cont..

RPSW mastership selection process

Membership selection is performed by primary ALSW. Primary ALSW samples four signals.

1. RPSW1 master capable? 2. RPSW1 watchdog OK?

3. RPSW2 master capable? 4. RPSW2 watchdog OK?

Notification of RPSW mastership throughout the system

Primary ALSW notifies both RPSWs of the mastership selection over SCB buses.

Primary ALSW notifies RPSW mastership selection to SW cards over SCB buses

Primary ALSW notifies RPSW mastership selection to Line cards over TCB


Master RPSW Failure

› 1. A master RPSW is operating normally. › 2. A Master RPSW error is detected and its master capable is released or its watchdog times

out. › 3. Primary ALSW determines the master RPSW is no longer master capable. › 4. Primary ALSW determines if standby RPSW is present. › 5. If standby RPSW present, then master RPSW switchover occurs. › 6. If no standby RPSW present, then no switchover occurs.


RPSW Faults Failover Behavior


SSR ALSW Overview


FPGA

Selection Control Bus

XGSwitch

RJ4

5

FS

Alarm Switch Card

BITS

Stratum3E

OSCO

BITS

Timing ref fm LC

RJ4

5 20 x GigE1 per LC

2 x 10GE1 per RPSW

Inter ALSW BUSBITS to LCs

ControlPlane}

Card Management Bus

PLL

Timing Control Bus

Switch Fabric control

FAIL

ACTV

STBY

H/S

PWR

FAN

CRIT

MAJ

MIN

ACO

ALARM LEDs


ALSW card hardware components

› FE (Fabric Switch Element) – Dune FE600› BITS/system clock circuitry› GE switch for control plane› Relay for alarms› Bus

– CMB (Command Management Bus)– TCB (Timing Control Bus)– SCB (Selection Control Bus)


Summary of ALSW Functions

› Switch fabric› Gbe switch› Clocking information › Alarm LED’s› Mastership selection› Watchdog Timers


SSR SW Card Overview


Switch CARD

› The SSR switch cards implement single FE platform. › SW use a Dune Networks® FE600 device.› The FE transmits both data and congestion control information across the fabric.› All switch cards are used in active mode.› In SSR8020 these cards are used to increase the backplane capacity.› In SSR8010 will not have switch cards.





Three Major components on a Line card• EZchip NP4 Network Processor• Dune (Broadcom) FAP100 (Petra B) Fabric Interface• Local Control Processor (LP)

• Freescale’s MCP8536 PPC Processor @ 1 GHz

• Currently two Line cards in SSR • Vogon: 10x10Gb Line card• Hitchhiker: 40x1Gb Line card

• PPA3LP introduced in 13B• Neptune introduced in 13B• Caldera introduced in 14B

• Line card memory• HH 2G• Vogon 2G• PPA3LP 4G• Caldera 8G


Smart Services Router40x1GE Line Card – ENET 1G

› 40x1GE line rate performance– Any combination of SFPs

› 1000Base-T SFP (100m)› 1000Base-SX SFP (550m)› 1000Base-LX SFP (40 km) › 1000Base-ZX SFP (70 km)

› 32,000 circuits/card– 8 CoS queues

› Port-based VoQ› SyncE timing› IEEE1588v2 timing

– TC: transparent clock– OC: ordinary clock– BC: boundary clock


NP4

SF

P

FAP

SF

PS

FP

SF

PS

FP

GbE PHY

SGMII QSGMII

STATS MEM

TMMEM

SRCH MEM

ACLMEM

STATSMEM

BUFFER

40 x 1 GbE Line Card

Interlaken

CONTROLCPU

GbE (SYS)

PCIe

RTCPLL

clock to/from SWALFPGA


Smart Services Router10x10GE Line Card – ENET 10G

› 10x10GE line rate performance– Any combination of XFPs

› 10GBase-SR XFP (~80 m› 10GBASE-LR XFP (~10-20 km)› 10GBase-ER XFP (~40 km)› 10GBase-ZR XFP (~80 km)› DWDM XFP (ch 35, 36, 37, 53, 55)


› Port-based VoQ› SyncE timing› IEEE1588v2 timing

– TC: transparent clock– OC: ordinary clock– BC: boundary clock


NP4

XF

P

FAP

XF

PX

FP

XF

PX

FP

XGPHY

5 x XFI 50G

STATS MEM

TMMEM

SRCH MEM

ACLMEM

NP4

STATS MEM

TMMEM

SRCH MEM

ACLMEM

XF

PX

FP

XF

PX

FP

XF

P

XGPHY

5 x XFI 50G

STATSMEM

BUFFER

10 x 10 GbE Line Card

FAP

STATSMEM

BUFFER

Interlaken

Interlaken

CONTROLCPU

GbE (SYS)

PCIe

PLL

PCIe

RTC

RTC

clock to / from SWALFPGA


Smart Services Router 40G Line Card for BNG

› Line Card– 4x10 GE XFP ports or 2x10 GE XFP + 20x1 GE SFP

ports› Software configurable

› High subscriber scale– 64k sessions/48k dual-stack sessions

› High touch services– Inline CG NAT, Advanced RADIUS Services– Flexible and granular H-QoS


Smart Services Router 1x 100GE / 2 x 40GE Line Card

› 1x100GE or 2x40GE – Software configurable

› Any combination of CFPs– 100GBASE-SR10 >100m MMF– 100GBASE-LR4 >10km SMF– 100GBASE-ER4 >40km SMF– 40GBASE-SR4 >100m– 40GBASE-LR4 > 10km


› Port-based VoQ


Smart Services RouterSmart Services Cards (SSC)

› Faster TTM with programmable SSCs– EPG, SASN, Caching, etc

› As many SSCs as needed– One Service per SSC– Multiple services per chassis– Load Sharing among SSCs

› Superior Control Plane scaling – Offloads routing processors– Faster, reliable control plane operation– Advanced multi-threading architecture– SSCs and line cards share switch fabric


Local Processor (LP)

› Freescale’s MCP8536 PPC Processor @ 1 GHz› 2GB USB Flash memory

– Used for storing Log files, images during upgrades. – This is a mounted drive

› 2 GB DDR3 RAM› 2 Gigabit Ethernet interfaces to ALSWs› PCIe link to the NP4(s)› Debug UART ports 0 & 1

– Console output from the linux kernel running on the LP


Port Mapping for Vogon Card

› NPU / NP4-0– Port 1-4 and 6

› NPU / NP4-1 – Port 5 and 7-10


Packet PATH

NIF NP4FAP FE600 NIFNP4

FAP

Line Card Line Card

Switch Card

(RP/AL/SW)

LPLP

GE switch

ALSW

GE controller Jasper Forest

RPSW

Ctrl traffic

Data traffic


SSR Fabric Overview


Mesh Backplane

› SE uses mesh backplane› Mesh Backplane

– All line cards have a direct connection to all other line cards.

- Pros– Fewer Physical Components– No single point of failure

- Cons– Complex backplane, many traces.– Not easily scalable.


SSR Switch Fabric

› SSR uses switch fabric (FE600), SE uses mesh backplane

› Switch Fabric– All Cards have a single connection to a central

switching component.

- Pros– Simpler backplane– Distributed Intelligence– Increased scalability

- Cons– More Physical components


8 power modules Rear external power cabling.

DC-only power sourceMax rated power of 16.8 kW

2 Fan Trays 6 fans per fan tray

Air outlets

20 Line Card slots forI/O or Service Cards;

Up to 40 SFPs per card

ETSI 600mm cabinet compliance

33RU (57.75”) high8 Switch Fabric cards, includes 4 cards

shared as 2 Route Processor and 2 Alarm Card

(4 SW, 2 SWRP, 2 SWAL)

L2/L3 and trunking line cards: 10x10 GE, 40x1 GE (11.2)

1x100(2x40) GE (13.1)

Subscriber services line cards:4x10(24x1) GE (13.1)

16x10GE (14.1)

Advanced services cards:SSC (12.2)

SSR-8020


SSR N20 Data Plane Topology

FE600

FE600

FE600

FE600

Petra_BNPUNIF100G

100G

FE600

FE600

FE600

Petra_B NPU NIF100G

100G

FE6002bits / LC

Petra_BNPUNIF

100G

100G

Petra_BNPUNIF

100G

100G

Petra_BNPUNIF100G

100G

Petra_BNPUNIF100G

100G

Petra_BNPUNIF100G

100G

Petra_BNPUNIF

100G

100G

Petra_BNPUNIF

100G

100G

Petra_BNPUNIF

100G

100G

Petra_BNPUNIF

100G

100G

Petra_B NPU NIF

100G

Petra_B NPU NIF

100G

Petra_B NPU NIF100G

Petra_B NPU NIF100G

Petra_B NPU NIF100G

Petra_B NPU NIF

100G

Petra_B NPU NIF

100G

Petra_B NPU NIF

100G

Petra_B NPU NIF

100G

LC Slot 4

100G

100G

100G

100G

100G

100G

100G

100G

100G

SWAL Slot 2

SW Slot 2

SW Slot 1

SWRP Slot 1

SWRP Slot 2

SWAL Slot 1

SW Slot 4

SW Slot 3

LC Slot 19LC Slot 9

LC Slot 10 LC Slot 20

LC Slot 18

LC Slot 17

LC Slot 16

LC Slot 15

LC Slot 14

LC Slot 13

LC Slot 12

LC Slot 11

LC Slot 8

LC Slot 7

LC Slot 6

LC Slot 5

LC Slot 3

LC Slot 2

LC Slot 1


Physical Components

› The SSR switch fabric has two essential components.– Fabric Access Processor (FAP)– Fabric Switch Element (FE)

› Each Line Card will have one or more FAPs.› The FE’s reside on Switch Card(s): RPSW, ALSW, and SW.

– The RPSW is a combination RP and SW card.– N+1 Protection.


Single FE Switch Fabric

› The SSR switch cards implement single FE platform. › With a single FE, the switch cards can provide 100G bandwidth for all line card

slots. 96 SERDES pairs from a FE are routed to the backplane. 4 SERDES pairs per slot for 100G bandwidth. Only up to 80 Serdes will be used to connect to line cards, the remaining 16 Serdes will not be used.


Fabric Switch Elements (FE)

› The SSR Switch Cards will use a Dune Networks® FE600 device.› The FE transmits both data and congestion control information across the

fabric.› The FE also performs a large portion of the Multicast solution through Fabric (or

Spatial) Multicast. Multicast packets are replicated to the line cards in the switch fabric, via the FE. The FE maintains the Multicast tables for fabric replication. (Port level replication is done by the NP.)


Forwarding Plane

FAP NPU

LC

FAPNPU

LCFE

SWRP

FE

SWRP

FE

SWAL

FE

SW

FAP NPU

LC

…

FAPNPU

LC……

› Fabric Access Processor (FAP) Broadcom (Dune) Petra-B FAP device

FAP receives packets from NPU and forwards them via switch fabric to a destination NPU

Each Line Card could have one or two FAPs Each FAP has two types of physical interfaces Network Interface (NIF): 12 or 24 Interlaken lanes

Fabric Interface (backplane): 32 x 4.735G FAP-FE links FAP connects to NPU via NIF

FAP connects to FE through fabric interface

› Fabric Element (FE) Broadcom (Dune) FE600 device

FE transmits both data and congestion control information across the fabric

Each FE600 supports 96x96/4.735G links to FAPs FE performs a large portion of multicast packet replication through

fabric (spatial) multicast Fabric interface links provide speedup with respect to Line Card line

rate


Switch Fabric

TM MAC

Line Card

TMMACPipeline

Processing

Line Card

Network Processor Unit (NPU)

FAP FAP Pipeline

Processing

Network Processor Unit (NPU)

› Line Card and Switch Fabric Functional split: packet forwarding vs. fabric forwarding Line card: packet forwarding (NPU) and fabric access (FAP) Switch fabric: fabric forwarding (FE)

› Packet Forwarding Functions Network Processor Unit (NPU):

› Classification, access control, statistics, QoS, header encapsulation, TM: platform dependent› Components: NP-4, PPA3LP, and Spider (PPA4)

(continued next page)

Forward Plane Functional View


(continued)

› Fabric Access and Forwarding Functions Fabric Access Processor (FAP):

› Fabric forwarding header encapsulation, scheduling, and VoQ

› Components: Petra-B

Fabric Switch Element (FE): › Supports a single stage CLOS cell-base switching network › Components: FE600


SSR Fabric Configuration (example)


Ingress FAP Configuration

› The NIF is configured as one or two Interlaken 12 Buses.› Each NIF connect to a single EZChip® NP-4.› Single Incoming FAP Port (IFP) mapped to a NIF.

Petra-B supports channelized NIF’s mapped to multiple IFPs, however initial SSR configuration will use unchannelized NIFs.

› Packets received on an IFP are mapped to a “System Physical Port” in the FAP, which represents a physical port in the chassis.


Virtual Output Queues (VOQ)

› Where packets are queued on the Ingress FAP. Primarily used for Unicast traffic. Each FAP can support 32K VOQs.

› Based on the Traffic Class of the packet, the FAP queues it into one of 8 VOQs assigned to the System Physical Port.

A fully loaded chassis with 40 ports per slot in 20 slots, or 6,400 VOQ’s. (40x20 x 8 = 6400)


Fabric Multicast Queues (FMQ)

› Fabric Multicast Queues are Ingress queues for multicast traffic. There are 9 FMQ’s per FAP. 1 for internal control traffic; 8 for multicast data traffic. Packets are only queued once and are not replicated on the IFAP. 4 queues are used as FMQs ( Fabric Multicast Queues) in R1. Control traffic and data traffic share the FMQs.


Relation of IFAP VOQs to EFAP ports

IFAP VOQ’s and EFAP Port Queues

FABRIC

Credit Flow

Data Flow

VIRTUA

L

NP4EFAP

IFAPNP4

NP4 IFAP


Egress FAP Configuration

› The Egress NIF is identical to the Ingress NIF. In fact, the NIF is bi-directional so it is shared by the Incoming FAP Ports (IFP) and Outgoing FAP Ports (OFP). Un-channelized Interlaken 12.

› There is 1 OFP for each LC physical port.› In addition, there is a “virtual” OFP defined for each NP.

Virtual OFP receives unicast packets without a destination port, as well as all multicast traffic. The egress line cards’ NPs are responsible for port level multicast replication. The “virtual” OFP has no special properties. To the FAP, all OFP’s are the same.


Fabric Multicast› Replication occurs at two points in the

data path.› On Ingress packets are marked as

Multicast by the Ingress NP.› The Ingress FAP Queues the packet

into a FMQ.› Packet is forwarded to the Switch (FE)

where it is replicated to all Egress FAPs in the Multicast Group.

› Egress NP replicates to all Ports in the Multicast Group.

Egress Line Card

Ingress Line Card Switch Card

Ingress NP Ingress FAP

Line Cards / Egress FAPs

Egress FAP

Egress NP

Port 1

Port 5

Port 4

Port 2

Port 3

Egress NP

Port 6

Port 10

Port 9

Port 7

Port 8

FE


Fabric Packet Scheduling & QOS

› Dune’s SAND™ architecture supports end-to-end scheduling.

– Credits are generated at the Egress FAP and flow back through each functional block to the ingress queues.

› At each level, there are options for defining the QOS elements (i.e. Scheduling Elements, Shapers).

› In SSR, the scheduling is configured once on the egress line card based on the physical configuration of the card and is not changed.

› Packet drops occur at the ingress queue’s preventing congestion in the fabric.

Queue Manager (RR)

NGP Sch(RR)

NGP Sch(RR)

ECI Sch(RR)

CPUSch(RR)

Phys.OFP OFP

NIF-

B

NIF

- A

ECI

Recy

c le P

ort

(unu

sed)

Phys.OFP

Phys.OFP

Phys.OFP

Phys.OFP

SWITCH

SP

Type-1High Res

Type-1High Res

Type-1High Res

OLP

(unu

sed)

Channel Sch(RR)

Channel Sch(RR)

Type-1High Res

VirtualOFP

Type-1High Res

Type-1High Res

Type-1High Res

Type-1High Res

Type-1High Res

HP UC

HP MC

LP UC

LP MC

System

Multicast

HP UC

HP MC

LP UC

LP MC

VOQ - H

VOQ - L

LB - H

LB - L

FMQ - H

FMQ - L

WFQ (H) WFQ (L)

WFQ (H) WFQ (L)

MM MM M M M M

sp sp

wfq

HP UC

LP UC

sp sp

wfq


Packet flow LC-to-SWRP

NIF NP4FAP

PetraBFE600 NIFNP4

FAPPetraB

Line Card Line Card

Switch Card(SWRP/SWAL/SW)

LPLP

GE switch

SWAL

GE controller Jasper Forest

SWRP

Ctrl traffic

Data traffic


Packet Flow

› Packets entering the FAP from the NP have an Incoming TM Header (ITMH) prepended. › The ITMH will identify the packet as a Unicast Direct or a System Multicast. › In the case of a Unicast Direct, the destination Physical System Port is specified along with the

Traffic class (TC). A Drop Precedence (DP) can also be programmed in the ITMH of the packet to select the WRED behavior. The NP will program the TC and DP from the QoS Parameters ( Priority and Color) of the packet.

› System Multicast packets will be queued in the FMQs. The ITMH in this case will identify the Fabric Multicast Group ID (FMGID). There are up to 16K FMGIDs available globally. The FMGIDs will be programmed for Fabric replication to the FAP device level.


Unicast Data Flow

ITMH – ingress TM header, FTMH – fabric TM header, OTMH – outgoing TM header


Fabric (IFAP-FE-EFAP) Unicast Packet Walk


Multicast Data Flow


Fabric Multicast

› Multicast replication Occurs at two stages for current SSR: FE and egress NPU

› Multicast packet walk Ingress packets are marked as Multicast by the Ingress NP. IFAP queues the packet into a FMQ. Packet is forwarded to FE, where it is replicated to all EFAPs in the Multicast Group. Egress NPU replicates to all Ports in the Multicast Group.

FAPNPU

Line Card

FE

Switch Card

FAP NPU

Line Card

NPUFAP

Line Card

Line Card

…

…

…



› Fabric Manager (FMR) provides centralized fabric management for the system. The FMR tracks the status of fabric components and fabric links (i.e. the fabric topology), calculates and configures unicast flows and multicast groups through the fabric, and provides a client interface through which other RP applications (processes) can interface to it.

› FAP Fabric Management Agent (fapFMA) is a process running on a card LP that communicates with the FMR to manage the FAP devices on the card. The fapFMA receives and acts on configuration requests from the FMR, and reports any changes in the fabric status to the FMR.


› FE Fabric Management Agent (feFMA) is a process running on the RP card that communicates with the FMR to manage the FE devices on SWRP, SWAL, SW cards. The feFMA provides the same type of functionality as the fapFMA, but is specialized for FE devices. Note that the FMR and feFMA communicate using IPC.

› Fabric Config (fabconf) is a library used by every FMAs and the FMR. It provides functional interfaces through which the card-type-specific fabric layout, default fabric device configurations, and FAPID/FEID information is retrieved.

› FMR Clients are applications (processes) that communicate with the FMR. Some examples are CSM and RCM.

› The FMR-Client Interface is used by FMR clients to communicate with the FMR.

› FMA Clients are applications that communicate with an FMA to configure unicast headers in the fabric endpoints.


Calculation for the throughput› 1. SSR 8020 最多支持 8 块 SW 板卡（ 2xRPSW + 2xALSW + 4xSW ） , SSR 8010 最多支持 4 块 SW 板卡（ 2xRPSW + 2xALSW ），

没有专门的 SW 板卡。› › 2. LC 上的 FAP 支持 32 个 SerDes 总线， SSR 8020 上，每个 SW 有 4 条 SerDes 到 LC ， SSR 8010 上，每个 SW 有 8 条 SerDes 到

LC 。› › 3. SSR 8020 每条 SerDes 总线的处理能力为 5.75Gbps ， SSR 8010 每条 SerDes 总线的处理能力为 6.25Gbps. 可以通过 fefma_test 来

获取 SSR 的 SerDes 的 Bandwidth ，但是这个 Bandwidth 是 raw rate ， effective bandwidth 的计算如下：› 8b/10b encoding (20% overhead)› VSC overhead (128B / (128B+9B) = ~6.4% overhead)› SSR8010: 6.25G * 0.8 = 5 Gbps, 5 * 0.934 = 4.67Gbps› SSR8020: 5.75G * 0.8 = 4.6Gbps, 4.6*0.934 = 4.2964Gbps› › 4. 下面的为提供线速转发时，所需的 SW 板卡计算。› › • 3 SW cards (3x4x4.2964Gbps)=51.5568G 40-port GE card in SSR 8020› • 6 SW cards (6x4x4.2964Gbps)=103.1136G 10-port 10GE card in SSR 8020› • 2 SW cards (2x8x4.67Gbps)=74.72G 40-port GE card in SSR 8010› • 3 SW cards (3x8x4.67Gbps)=112.08G 10-port 10GE card in SSR 8010› 因此我们说 SSR 8020 的 SW 为 6+2 备份 ( 文档讲 7+1) ， SSR 8010 的 SW 为 3+1 备份。


SSR IPOS Software


IPOS Software Architecture

Modular fully 64 bit Operating System

Line Card Line Card

Network Management Interface

BGP ISIS OSPF MCASTConfiguration process

Configuration management

MPLS SNMP

SSR : Linux Kernel

Interface State

Manager

› Ericsson IP Operating System for SSR is based on the same carrier-grade operating system that has been field-proven in by over 300+ carriers on the SmartEdge

› All major functions are split into separate processes– Routing processes run in separate protected spaces– Protocols maintain separate databases– Easy fault isolation

› Individual processes can be updated and restarted without

any service disruption› Forwarding functionality reside in the line cards


Ericsson IPOS Software

› Common Manageability – (CLI, SNMP, NBI)

› IP Feature Richness

› Carrier Grade Foundation (Linux-based) for scale and performance

› Virtualization Support

› Supported on multiple platforms

IP Protocols and Services

Platform Hardware & Software (i.e. Linux)

Abstraction Layer Adaptation

Forwarding Data Plane (NP4, BRCM, Spider)

Applications for Market (optional)

IPOS Management Command Line Interface, SNMP, NBI

IPOS InfrastructureDistribution, Abstraction of HW/Physical location, Resource Mgmt

IPOS is the common software across portfolio


Software architecture

Ericsson IP Operating System SW:L2, L3, IP/MPLS, VPN, Multi-layer

BG

F

CD

N

SA

SN

(D

PI)

EP

G

BN

G

MS

ER

CG

-NA

T

Hardware Abstraction SW

FASTER FEATURE VELOCITY and APPLICATION INTEGRATION

PLATFORM INDEPENDENT ARHICTECTUREMODULAR CARRIER GRADE OPERATING

SYSTEM

LEVERAGE ERICSSON PROVEN APPLICATION SOFTWARE


IP V4 Routing Protocols› Static Routing

– Dynamic verified Static routes using ICMP or BFD› RIP› OSPF / IS-IS

– Fast convergence (event driven mode to allow immediate SPF calculation)

– fall back to timer SPF calculation in case of network instability

› BGP4› PIM/IGMP› Load sharing

– ECMP on 16 paths– Hashing based on 5tuple

› IP src/ dest, IP protocol, TCP/UDP port src/dest

– Link Aggregation on Ethernet (802.3ad)› High availability

– NSF supported for OSPF, IS-IS and BGP– Graceful Restart for OSPF, IS-IS and BGP– NSR for OSPF and IS-IS– BFD supported for all protocols (3ms minimum timer)– Inter-Chassis Redundancy

IPv4

SSR

SSR SSR

SSR


IPV4 Routing ScalabilitySSR

RIB Routes 8 M

OSPF Routes 512 K

OSPF Adjacencies 3,000

ISIS Routes 512 K

ISIS Adjacencies 512

BGP-4 Routes 60 M

BGP-4 Peers 5,000

FIB Routes 8 M

BFD 4K / LC

IPv4

SSR

SSR SSR

SSR


IPv6

IP V6 Routing Protocols

› IPV6 Routing– Static Routing – RIP NG– OSPFv3– IS-IS– PIM/MLD

› Redundancy– IPV6 over Link Aggregation (802.3ad)– ECMP– Graceful Restart for OSPv3 and BGP4+

› IPV6 System Utilities– Ping – Traceroute

– BGP4+– Dual Stack Support

– 6PE– 6VPE

SSR

SSRSSR

SSR


IP V6 Routing Scalability

SSR

IPV6 RIB Routes 2 M

OSPF Routes 512 K

OSPF Adjacencies 3,000

ISIS Routes 512 K

ISIS Adjacencies 512

IPV6 BGP4+ Routes 60 M

IPV6 BGP4+ Peers 5,000

IPV6 FIB 1 M

IPv6

SSR

SSRSSR

SSR


MPLS

MPLS

› Signalling– LDP– RSVP-TE

› RSVP-TE– FRR– CSPF– Make Before Break– IGP shortcut

› Services– L3VPN (v4, 6PE, 6VPE)– L2VPN (p2p and mp2mp)

SSR

SSRSSR

SSR


MPLS High Availability› LDP and RSVP-TE Graceful Restart› LDP/IGP Synchronization

– Max metric advertised per link by IGP until :› LDP Adjacency established on the link› LDP Session established› Label exchange complete

– Supported for OSPF and IS-IS› Path protection with multiple backup schemes:

– Backup Path– Backup of backup path– <100 ms protection

› MPLS Fast Reroute Link and Node Protection


MPLS Scalability

SSR

Non-targeted LDP Peers 200

Targeted LDP Sessions 1,800

MPLS LDP LSPs 512,000

MPLS RSVP-TE LSPs 80,000

GRE Tunnels 20,000

MPLS

SSR

SSRSSR

SSR


FAST CONVERGENCE & OAM› BFD

– Static, OSPF, ISIS, BGP, RSVP-TE, PIM– Minimum timer 3ms

› IGP Prefix prioritization› IGP Prefix hiding› BGP best-external and diverse path

› Dual Barrel Next Hop› IP FRR with Fast Notification

› TWAMP


Why IPFRR?› Switch-over times that are comparable to those of Sonet/SDH, MPLS FRR and carrier-grade

Ethernet– Target: <50ms fail-over

› Example measurement results for fail-over time:– OSPF with Hello based failure detection: >2 seconds– OSPF with L2 upcall or BFD: 150-300ms– IPFRR: 20-30ms

outage with OSPF

outage with IPFRR

Example:


Trigger mechanisms› BFD› Port/circuit failure› Card failure› Fast Failure Notification (FFN)› Event Tracker Infrastructure (ETI)

S

N1

N D

2

11

1

1

3.1.1.1

1.1.1.1

2.1.1.1

BFD

RIB, FABL, ALD:

PFE:

3.1.1.0/24CNH 1.1.1.1

CNH 2.1.1.1

CNH 1.1.1.13.1.1.0/24

CNH 1.1.1.1 ADJ 1.1.1.1

CNH 2.1.1.1 ADJ 2.1.1.1

Double Barrel NH

CNH 1.1.1.1 refCNH 2.1.1.1 ref

Double Barrel NH

Ingress Egress

ADJ 1.1.1.1

ADJ 2.1.1.1

CNH 2.1.1.1

Triggers BFDDouble Barrel is over written


L2 Point to point› Local cross-connect› VPWS

› Flexible VLAN matching– Untag– Priority tagged– Dot1q VLAN– Dot1ad VLAN– Fallback c-tagged– Default

– VLAN range (e.g. 5-15) for S-VLAN and C-VLAN– * for S-VLAN and C-VLAN

– PPPoE, IPv4, IPv6 encapsulation

› Flexible VLAN manipulation– 3 possible operations: PUSH, POP, SWAP

– 2 VLAN manipulations in ingress direction– 2 VLAN manipulations in ingress direction

L2 P2P

SSR

SSR SSR

SSR


VPWS

› Backup pseudo-wire through draft-Muley

› Assign pseudo-wires to RSVP-TE LSP

CE PE

PE

PE

CE

PWBackup PW


L2 point to point

SSR

L2 XC (2 circuits per XC) 128K

VPWS 256K

Targeted LDP 1,800

Number of L2 circuits per linecard

40 x 1GE 24,000

10 x 10GE 48,000

L2 P2P

SSR

SSR SSR

SSR


› QoS supported:– Policing– Metering– PWFQ– WRED– Propagation

QoS on L2 Services


Bridging› Service-instance access circuit (VLAN matching and manipulation)

› Static/dynamic MAC table

› MAC aging

› MAC learn limit

› Broadcast/multicast/unknown rate-limit

› MAC move detection


Bridging› Distributed learning

› Once linecard will learn new source MAC address and distribute it to the other linecards in the same bridge without going through RP

› Qualified learning› Qualified and unqualified learning mode is configurable per bridge› With qualified learning enabled, each VLAN in the same bridge has a separate MAC table –

its own broadcast domain

› Split Horizon Groups› Circuit can only send packets to circuits in another SHG group


Bridging SCALING

SSR

MAC per linecard 1M

MAC per system 20M

MAC learning rate 215K/sec per LC

Bridge instances 12,000

Access Circuit per bridge 1,000

Bridge access circuits per linecard

40x1GE 24,000

10x10GE 48,000

SSR


VPLS› Service-instance access circuit (VLAN matching and manipulation)› Distributed learning› Qualified learning› Split Horizon Group even on PW

- Hub PW will be part of an implicit SHG for loop prevention, so will be limited to one additional SHG

› LDP signaling› Flat VPLS› H-VPLS› PW redundancy› PW mapping to LSP


VPLS SCALING

SSR

SSR SSR

SSR

VPLS

SSR

MAC per linecard 1M

MAC per system 20M

VPLS instances 12,000

VPLS PW per bridge 2K

VPLS PW per system 24K

Targeted LDP sessions 1,800

VPLS access circuits per linecard

40x1GE and 2x40GE/1x100GE

24,000

10x10GE 48,000


L2 OAM› 802.1ag (CFM)

– MEP and MIP

› Y.1731

› Triggers for ETI/MC-LAG


L2 OAM SCALING

SSR

SSR SSR

SSR

VPLS

SSR

Scaling per linecard

802.1ag/Y.1731 3.3msec timer 200

802.1ag/Y.1731 10msec timer 1,000

802.1ag/Y.1731 100msec timer 4,000

802.1ag/Y.1731 1sec timer 8,000

Scaling per system

802.1ag/Y.1731 3.3msec timer 4,000

802.1ag/Y.1731 10msec timer 12,000

802.1ag/Y.1731 100msec timer 64,000

802.1ag/Y.1731 1sec timer 128,000


SSR NEW Feature in R1

Next Generation L2(IPOS R1)


Introduction

› SSR can provide carrier-class reliability, scalability and performance, have minimal power requirements.

› SSR combines multiple functions into a single platform that provides Layer 3 IP provider edge (PE) and Provider (P) Unicast and Multicast routing, Layer 2 Ethernet network aggregation, and other services.

› SSR can be used in solutions that combine Layer 2 and Layer 3 for both fixed and mobile network.


Layer 2 network

› Layer 2 Virtual Private Networks (L2VPNs) based on Virtual Private Wire Service (VPWS) —Provides end-to-end Layer 2 cross-connected circuits over IP and MPLS core networks

› Ethernet to Ethernet Layer 2 Local cross-connect

CE

PE

CE

MPLSCore PE

SSR port

Service-instances CE

Pseudowire

Local XC


› SSR Target Applications

› Local Cross Connections and VPWS

› Local Cross Connections Configuration

› VPWS Configuration


L2 features on SSR 11.1› SSR 11.1 release has introduced the L2 cross-connect features.

– Local Cross-Connections– VPWS

(* Bridge and VPLS features are expected in 14A)

› To enable these L2 services, 2 types of new circuit related configuration concepts have been introduced.

– Service-Instance– Pseudowire-Instance

› Using these instances, SSR can provide flexibility of circuit definition and VLAN manipulation, and L2 services.


Layer 2 network› Local Cross-Connections:

– Ethernet to Ethernet Layer 2 cross connect within single SSR

› VPWS:– Provides end-to-end Layer 2 cross-connected circuits over IP/MPLS networks

CE

PE

CE

MPLSCore PE

CE

Local XC

VPWS


Terminology› AC Attachment Circuit

– The physical or virtual circuit attaching a CE router to a PE router.

› SI Service Instance– An attachment circuit using Ethernet encapsulation that is configured for L2 forwarding and

manipulation and transportation of various types of packet encapsulations

› PWI Pseudowire Instance– A pseudowire which emulated point-to-point connection over an MPLS network that allows

the interconnection of two nodes with any L2 technology.


Local Cross Connections› Local cross-connections allow you to connect two Layer 2 Ethernet service instances to each

other. › The configuration of the cross-connected service instances, determines how Ethernet traffic is

forwarded from the service instances on one port to the service instances on another port of the same SSR.

SSR

CE1

Service-Instance 1

CE2

Service-Instance 2

Cross Connect (xc)

Point-to-Point L2 connection


VPWS› VPWS is a point-to-point link between two CE routers through MPLS based pseudowire network. › SSR performs cross connect the local service instance SI circuit (between the local CE and PE) to

a pseudowire (PW) instance that crosses the MPLS backbone network to the remote PE router.

PE1

CE1

Service-Instance 1PW-Instance 1

Cross Connect (xc)

Point-to-Point L2 connection PE2

CE2

Service-Instance 2

Cross Connect (xc)

PW/MPLS

PW-Instance 2








› L2 and L3 Features Overview



› VPWS Configuration 1. Service Instance and XC

2. VLAN Tag Matching

3. VLAN Tag Manipulation


Service Instance› An attachment circuit using Ethernet / 802.1Q / 802.1ad encapsulation between

CE and PE.

› Service instance has two functionality for flexible VLAN tag operation– VLAN Tag Matching– VLAN Tag Manipulation

› Instances for cross-connection:– Local Cross Connections: between two service instances– VPWS: between service instance and pseudowire instance


Service-instance configuration› To create a Layer 2 VLAN service instance under a parent Ethernet port configuration and access service

instance configuration mode.

Create a Single Service Instance:[local]Ericsson(config)#port ethernet 4/1[[local]Ericsson(config-port)#encapsulation dot1q[local]Ericsson(config-port)# service-instance 1

Create a Range of Service Instances:[local]Ericsson(config)#port ethernet 4/1[[local]Ericsson(config-port)#encapsulation dot1q[local]Ericsson(config-port)# service-instance 20 - 30


Service co-existence› Dot1q PVC and NGL2 can exist together without collision:

[local]Ericsson(config)#port ethernet 4/1[[local]Ericsson(config-port)#encapsulation dot1q[local]Ericsson(config-port)#dot1q pvc 100[local]Ericsson(config-pvc)#bind interface to-pe1 local[local]Ericsson(config-port)#service-instance 120[local]Ericsson(service-instance)#match[local]Ericsson(service-instance)#dot1q 101


XC configuration

[local]Ericsson(config)#xc-group XC1[local]Ericsson(config-xc-group)#xc 5/7 service 6 to 5/8 service 8

› xc-group {default | group-name}– Creates an empty group of cross-connected circuits or selects an existing one and accesses XC

group configuration mode.

› xc– Creates a cross-connection between an SI (or SI range) and a PW or a cross-connection

between an SI and another SI (or between SI ranges).


Configuration Overviewcard ge-40-port 1!port ethernet 1/38 no shutdown encapsulation dot1q service-instance 1 match dot1q 1000!port ethernet 1/39 no shutdown encapsulation dot1q service-instance 1 match dot1q 1000!!xc-group XC1 xc 1/38 service-instance 1 to 1/39 service-instance 1

Under ethernet port configuration, service-instances are defined with match options.

Using “xc” command, two service instances are cross connected to each other.


Exercise: Local Cross Connections Config

port ethernet 1/38 no shutdown encapsulation dot1q service-instance 1 match dot1q 1000

XC1

Service-instance 1Dot1q pvc VLAN=1000


1/38 1/39

xc

port ethernet 1/39 no shutdown

encapsulation dot1q service-instance 1

match dot1q 1000

xc-group XC1 xc 1/38 service-instance 1 to 1/39 service-instance 1

STEP1: Setting up Service instance

STEP2: Cross Connect two Service Instances


Exercise: Local Cross Connections Config

› STEP3: Verify XC status

[local]Ericsson#show xc**BYPASS XC**Circuit State XC Circuit State1/38 service-instance 1 Up 1/39 service-instance 1 Up


Exercise: Range of Service Instances

port ethernet 1/38 no shutdown encapsulation dot1qservice-instance 2 - 5 match dot1q 1100

XC1

Service-instance 2 - 5Dot1q pvc VLAN=1100 - 1103

Service-instance 2 - 5Dot1q pvc VLAN=1100 – 1103

1/38 1/39

xc

port ethernet 1/39 no shutdown encapsulation dot1q service-instance 2 - 5 match dot1q 1100

xc-group XC1 xc 1/38 service-instance 2-5 to 1/39 service-instance 2-5

STEP2: Cross Connect two Service Instance ranges

STEP1: Setting up Service instance range


Exercise: Range of Service Instances› STEP3: Verify XC status

[local]Ericsson#show xc**BYPASS XC**Circuit State XC Circuit State1/38 service-instance 2 Up 1/39 service-instance 2 Up1/38 service-instance 3 Up 1/39 service-instance 3 Up1/38 service-instance 4 Up 1/39 service-instance 4 Up1/38 service-instance 5 Up 1/39 service-instance 5 Up

<- 1100

<- 1101

<- 1102

<- 1103

Assigned VLAN-ID (Not displayed)





› VPWS Configuration1. Service Instance and XC




VLAN tag matching options› Use the match command to access VLAN match configuration mode, where you can configure VLAN tag

matching criteria that designates different Layer 2 service instances for carrying specific types of traffic.

dot1q For Dot1Q traffic (single tagged) received by the port.

dot1ad For Dot1AD traffic (single and double tagged) received by the port.

untagged For untagged traffic received by the port or any traffic double tagged with an ethertype different from the one configured with “dot1q tunnel ethertype”.

priority-tagged For priority-tagged traffic received by the port (with vlan-id= 0 + priority bits).

fallback-c-tag For single tagged traffic with ethertype 0x8100 received by the port.This match option specifies a transport VLAN for forwarding 8100-type tagged traffic that does not match any other transport VLAN.

default A default match option for the port. This match option specifies a default circuit that captures packets that do not match the criteria for any other service instance.


VLAN tag matching restrictions

› A service instance can handle packets with up to 4 stacked VLANs, the matching criteria is only matching on the two outer VLANs.

› An individual (non-range) service instance can have up to four match options

› A range service instance can have only one match option


Optional encapsulation type

› ipv4oe– Captures IPV4 over Ethernet-encapsulated packets only.

› ipv6oe– Captures IPV6 over Ethernet-encapsulated packets only.

› pppoe– Captures PPPoE-encapsulated packets only.


Match option example

port ethernet 1/1 encapsulation dot1q service-instance 1 match dot1q 5 pppoe service-instance 2 match dot1q 5

Although service instance 2 does not have an encapsulation specified, the router automatically filters non-PPPoE packets to service instance 2 because service instance 1 has PPPoE filtering enabled.

All Dot1Q PPPoE packets that have a VLAN of 5.

All Dot1Q IPv4- or IPv6-over-Ethernet packets with a VLAN of 5.


Match hierarchyHierarchy Match Criteria

1. Dot1AD S-VLAN (single-tagged) and S:C-VLAN (double-tagged) packets with encapsulation (PPPoE, IPv4 or IPv6).

2. Dot1AD S-VLAN (single-tagged) and S:C-VLAN (double-tagged) packets without encapsulation.

3. Dot1Q C-VLAN packets with encapsulation (PPPoE, IPv4 or IPv6).

4. Dot1Q C-VLAN packets without encapsulation.

5. Priority tagged packets with encapsulation (PPPoE, IPv4 or IPv6).

6. Priority tagged packets without encapsulation.

7. Untagged packets with encapsulation (PPPoE, IPv4 or IPv6).

8. Untagged packets without encapsulation.

9. Priority tagged and fallback-C-tagged packets.

10. All packets that match the default option.

11. Unmatched packets.


Match hierarchy

port ethernet 17/1 encapsulation dot1q service-instance 1 match

dot1q 5 service-instance 2 match

dot1ad 5 service-instance 3

match dot1ad 5:10

service-instance 4match fallback-c-tag

service-instance 5match default

All Dot1Q packets that have a VLAN of 5.

All Dot1ad (double tagged) packets with a S-VLAN of 5, except 5:10.

All Dot1ad packets with tag 5:10.

All Dot1Q packets (single tagged) with all VLAN except 5.

Any previously unmatched dot1q/dot1ad including untagged packets

Hierarchy is not based on SI numbering but on the most specific tagging


Matching Dot1Q VLANs and VLAN Rangesdot1q * Configure a Dot1Q match option for a single tag VLAN with ethertype 0x8100 (any

VLAN-ID in the range from 1 through 4094), excludes any more specific dot1q options

dot1q vlan-id [encapsulation-type] Configure a Dot1Q match option for a specific VLAN

dot1q start-c-vlan - end-c-vlan Configure a Dot1Q match option for a range of VLANs

port ethernet 17/1 encapsulation dot1q service-instance 2 match dot1q 5 - 10

VLAN-ID from 5 to 10


Matching Dot1AD VLANs and VLAN Ranges

dot1ad * To match a wildcard S-VLAN (any S-VLAN identifier in the range from 1 through 4094).

dot1ad * :c-vlan To match a wildcard S-VLAN (any S-VLAN identifier in the range from 1 through 4094) and a specific C-VLAN.

dot1ad s-vlan: * To match a specific S-VLAN and a wildcard C-VLAN (any VLAN identifier in the range from 1 through 4094).

dot1ad s-vlan [: c-vlan] [encapsulation-type] To match a specific S-VLAN and C-VLAN with a particular encapsulation type:

dot1ad start-s-vlan - end-s-vlan [: c-vlan] To configure a dot1AD match option for a range S-VLANs and, optionally, a specific C-VLAN:

dot1ad s-vlan : start-c-vlan - end-c-vlan To configure a dot1AD match option for a specific S-VLAN and a range of C-VLANs

port ethernet 17/1 encapsulation dot1q dot1q tunnel ethertype 88a8 service-instance 16 match dot1ad 5 - 15 : 200

All S-VLAN from 5 through 15 with a C-VLAN value of 200.


Exercise: Dot1ad Service Instances

port ethernet 1/38 no shutdown encapsulation dot1q dot1q tunnel ethertype 88a8 service-instance 6 match dot1ad 2000 : 1 ipv4oe

XC1

Service-instance 6Dot1ad pvc 2000:1 (IPv4)

1/38 1/39

xc


STEP2: Cross Connect two Service Instance

STEP1: Setting up dot1ad Service instance range

Service-instance 6Dot1ad pvc 2000:1 (IPv4)

port ethernet 1/39 no shutdown encapsulation dot1q dot1q tunnel ethertype 88a8 service-instance 6 match dot1ad 2000 : 1 ipv4oe





› VPWS Configuration1. Service Instance and XC




VLAN Tag Manipulation› In addition to VLAN tag matching options, the service-instances have VLAN Tag Manipulation

functionality.› With VLAN tag manipulation, you can enable modify the VLAN tags of packets between SI.

› Under a service-instance configuration, “vlan rewrite” command enables to access VLAN rewrite configuration mode.

› After you access VLAN rewrite configuration mode, you can use the ingress and egress commands to modify the layer 2 tags of an incoming packet.

› Possible tag operations are push, pop, and swap.


VLAN rewrite› VLAN tag rewrites can be performed for the two outer tags only. › An individual circuit can be configured with a maximum of two ingress rewrites and two egress

rewrites at any time.

› The following constructs are valid for push and swap operations only: – dot1q vlan-id – dot1ad tag – priority-tagged

› Tags swapped and pushed by the router must match the egress side match options.


Basic vlan-rewrite example (asymmetric)

[local]Ericsson #configure[local]Ericsson(config)#port ethernet 17/1[[local]Ericsson(config-port)#encapsulation dot1q[local]Ericsson(config-port)#service-instance 1[local]Ericsson(config-port)#dot1q tunnel ethertype 88a8[local]Ericsson(service-instance)#vlan-rewrite[local]Ericsson(vlan-rewrite)#ingress seq 1 pop outer[local]Ericsson(vlan-rewrite)#ingress seq 2 push inner dot1q 10[local]Ericsson(vlan-rewrite)#egress seq 1 push outer priority-tagged[local]Ericsson(vlan-rewrite)#egress seq 2 swap inner dot1q 5

On the ingress direction, the outer label is popped, and a new 802.1Q inner label is added to the packet.

On the egress direction, the circuit adds an outer priority-tag to the packet, and then replaces (swaps) the next inner tag with the tag dot1q 5.


Symmetric configuration› Performs the configured operation in the opposite sequence for the egress direction. If you

specify seq 1 for an ingress operation, that operation is performed in the opposite sequence (seq 2) in the egress direction.

› The symmetric keyword is available for ingress rewrites only. (you cannot specify the symmetric keyword with the egress command)

› If you use the ingress command configure a ingress operation with the symmetric option, you cannot configure an egress operation with the same sequence number.

› A maximum of two symmetric operations can be simultaneously specified under a service instance.


Symmetric example

[local]Ericsson(service-instance)#vlan-rewrite[local]Ericsson(vlan-rewrite)#ingress seq 1 pop outer symmetric[local]Ericsson(vlan-rewrite)#ingress seq 2 swap inner dot1q 30 symmetric

Ingress Direction:• The service instance removes (pops) the outer C-VLAN tag to the packet first,• And then replaces (swaps) the next tag (the tag that was next to the outer C-VLAN tag that was popped)

with Dot1Q VLAN C-tag 30. • This operation results in Dot1Q VLAN tag 30 being the outer tag: Egress Direction:• In the egress direction, the service instance replaces the inner tag with Dot1Q VLAN C-tag 30, • And then pops the outer tag. • This operation results in Dot1Q VLAN tag 30 being the outer tag.


Exercise: VLAN Tag Manipulation


XC1

Service-instance 1

1/38 1/39

xc


STEP2: Cross Connect two Service Instance

STEP1: Setting up Service instances with vlan-rewrite

port ethernet 1/39 no shutdown encapsulation dot1q service-instance 7 match dot1q 3000 vlan-rewrite ingress seq 1 swap outer dot1q 1000 symmetric

Service-instance 7







VPWS topology

• The purpose of a VPWS configuration is to connect a local CE router to a remote CE device through an existing MPLS backbone network.

CEPE

PE

PE

CE

PW

Backup PW


Configuration Overviewpseudowire peer-profile PE1 peer 1.1.1.1 vc-type vlan

pseudowire instance 1 pw-id 100 peer-profile PE1

port ethernet 1/15 shutdown encapsulation dot1q service-instance 1 match dot1q 10

xc-group default xc 1/15 service-instance 1 to pseudowire instance 1

Create a new pseudowire peer profile

Create a new pseudowire instance or range of instances

Create a new service instance or range of instances

Cross connect the service instance to the pseudowire instance

In addition to above configuration, MPLS & IP routing configurations are required.


show xc pw[local]Ericsson(config)#show xc pw detail

PW ID : 100 Peer : 1.1.1.1Context : Local Instance : 1L2 state : Down PW state : DownL2 Circuit : 1/15:511:63:31/1/2/8 PW Circuit : 255/12:2:37/0/1/1Local label : 131072 Remote label : 0Local PW MTU : 1500 Remote PW MTU : 0Local PW Type : VLAN Remote PW Type : UnknownLocal PW Status : forwarding Remote PW Status : n/aLSP Configured : LDP-PATH LSP Used :Peer-profile : PE1 Bound to : 1/15 service-instance 1Flags : : bound


VPWS with PW redundancypseudowire peer-profile PE1 peer 1.1.1.1

pseudowire instance 1 pw-id 100 peer-profile PE1 backup-peer 13.1.1.1 pw-id 102 signaling-proto ldp



PW redundancy is supported on LDP-signaled PWs only.

Specify the IP address of the PW backup peer.


VPWS attached to an LSPpseudowire peer-profile PE1 peer 1.1.1.1 tunnel lsp rsvp lsp-to-pe1

pseudowire instance 1 pw-id 100 peer-profile PE1 backup-peer 13.1.1.1 pw-id 102 port ethernet 1/15 shutdown encapsulation dot1q service-instance 1 match dot1q 10


The pseudowire will use the LSP created through RSVP


Scaling figures as of IPOS 11.1

802.1Q Xconnections (2 circuits/XC) – system wide 128K

VPWS 256K


Number of circuits xconnected / connected to a PW per linecard

40 x 1GE 32,000

10 x 10GE 64,000


Coming L2 features› Features in 12B

– VLL over LAG

› Features in 13A– XC over LAG – QoS services on NGL2 (policing, metering, queuing on AC and propagation)– 802.1ag – SNMP MIB and trap on L2VPN redundancy– CLI to manually switch-over redundant L2VPN

› Features in 13B– L2ACL on NGL2– Circuit/port mirroring– SyncE


Coming L2 features

› Features in 14A– Bridging– VPLS– VPLS advertise using BGP– Port PW– Y.1731

› Features in 14B– BVI– MS-PW– 802.3ah

Qos on NP4(IPOS R1)


QOS Overview

› SSR QoS functionality is similar to that of SmartEdge

› NP4 QoS capabilities are similar to those of PPA2/PPA3

› Existing CLI reused in most cases with minor modifications

› Most of the differences are minor and internal

› New internal feature is Resource Management for QoS

› QoS is implemented both in NP4 and the Switch Fabric


Propagation› SSR maintains a six-bit PD-QoS value for each packet

– Same as SmartEdge– Internal Packet Descriptor (PD) has three bits of priority and three of drop-precedence

(pppddd)

› The initial PD-QoS value determined by priority value in packet header. – “propagate qos from ip / ethernet / mpls”

› PD QoS may be propagated back to the packet on egress– “propagate qos to ip/ethernet/mpls” command

› Propagation can be customized by ingress and egress class-maps


Policing and Metering› Policing is Ingress & Metering is egress classification & rate-limiting› Single rate, two-color or three-color› Actions can be to mark PD QoS, mark IP DSCP, or drop› SSR Variations:

– Class based and Circuit based policing / metering happens in parallel and not sequential.– Packets dropped at class-level may in some cases be counted against the circuit-level rate

› Hierarchical Policing and Metering: “inherit” or “hierarchical”› Up to two metering and two policing policies for a circuit

– Only one classification, though, so the “lower” bindings classification result must be mapped to a parent class


Queuing and Scheduling› SSR Supports only PWFQ queuing policy› PWFQ can schedule 10GE ports without TM2 “virtual-ports”› PWFQ bindings are inherited to children without more direct bindings by default› SSR Variation

– Each policy can have only one shaped priority-group i.e we can configure max rate only on one PG.

– each queue can have a max rate configured: › “queue <n> {rate <kbps> | rate percentage <value>}”

› WFQ on PG0 is not supported › Minimum rate on a egress queue not supported› Minimum rate on the policy can not be configured if is has a Priority Group shaper


Queuing and Scheduling› Circuit is a L2 node which can be grouped into L3 nodes

› On NP4 there are a maximum of 32 L4 nodes. Hence the port mapping in 10x10 and 40x1 cards are different

– 10x10: Ports mapped to L4 nodes & can have upto 2 levels of L3 nodes– 40x1: Ports mapped to L3 nodes & can have only one L3 node.


Queuing and Schedulingqos policy pwfq-Not-OK pwfq

rate maximum 1000num-queues 8 queue 0 priority 0 weight 60 <== WFQ on P0 is not supportedqueue 1 priority 0 weight 40 queue 2 priority 1 weight 100 queue 3 priority 4 weight 50 queue 4 priority 4 weight 50 queue 5 priority 5 weight 100queue 6 priority 6 weight 70 queue 7 priority 6 weight 20queue priority-group 4 rate 200

queue priority-group 6 rate 500 <== multiple Priority Group shapers are not supportedqueue 2 rate maximum 100

› In this case queues 0 & 1 will have equal weight› We have two shaped PGs configured which is invalid


Congestion avoidance

› Works like SmartEdge› Up to three RED profiles per queue› SSR Variations:

– RED profiles and absolute queue depth are mutually exclusive– RED profile exponential weight is not configurable


QoS Feature Implement in NP4 and Fabric

IngressQoS Propagation

IngressQoS Classification

Policing

Ingress Shaping

ForwardingDecision

NP-4 TOPS

Switch Fabric

INGRESS QoSTABLES

INGRESS QoSFEATURES

Ingress FabricQueuing

Ingress FabricScheduling

STATICFABRIC

PARAMETERS

CLASS MAPS

CLASS DEFINITIONS

POLICY ACLS

TOKEN BUCKETS

POLICING ACTIONS

SHAPING PARAMETERS


Resource Management› QoS specific resources are managed internally on the RP› Any object (policy, class-map, congestion-map, etc.) or object reference may

have a set of associated resource on the NP4› The resources are mapped on a per NP4 basis› We will gets an error if a binding or a configuration needs a resource that isn’t

available.


CLI Commands for Fabric

› The following command shows the VOQ statistics from the Line card– show card 1 fabric-stats dest-slot n dest-port n

› Counters for the FMQs – show card 1 fabric-stats multicast

› Counters from the FAP– Aggregate counters from a FAP on a LC– show fabricd card 1 statistics all


QoS Troubleshooting› QoS information from RP

– Command same as before : show qos …– Additional optional keyword at the end is “resource” that can be used to find the local NP4 ID

for a policy– ISM Log for Qos Process

› sh ism client qos log

› Information from FABL QoS:– show card 1 fabl qos

› ALD QoS FABL API log: Shows messages sent by FABL to ALD regarding QoS– show card 1 fabl api log control module qos [detail]


QoS Troubleshooting› For QoS info for a circuit from NP4 :

– show card # pfe # circuit handle <> detail

PD Info :: local_cct_idx = 3, pi-hdl=0x1FFFF18000009Ingress Circuit::…feat_mask = 0xe2800 :qos_prop_from_dscp ecmp_lb_hash qos_prop_from_mpls_use_map qos_prop_from_mpls_eth_inner ip_class_map_id=0 eth_class_map_id=0

Ingress Circuit Extension:: tcam_profile=0, fwd_policy_id=0x0 acl_rule_id[0]=0x0 acl_rule_id[1]=0x0acl_rule_id[2]=0x0 acl_rule_id[3]=0x0

Egress Circuit :: … queue_map[0..3]=[0x54 0x51 0x32 0x00] ckt_ipg=0x0cong_map_id=0x 1,mtu=0x 644,ckt_id=0x3,ip_class_map=0x 0,eth_class_map=0x 0,class_def_id=0x 0,tm_counter=0x0feature_mask = 0x6200 : cong_avoid, qos_prop_to_mpls_use_mapmpls_class_map=3,fwd_policy_id=0x0, l2vpn_class_map=3


QoS Troubleshooting

› To get policy details from NP4 itself› First step is to get a local identifier for that policy in a given NP4

[local]SR1#sh qos policy pwfq PWFQ-DIV-NAN resourcesSl/Pfe handle1/0 1

› Use the handle to get information for the policy:– show card 1 pfe 0 qos queuing handle 0x1 detail

[local]SR1#sh card 1 pfe 0 qos queuing handle 0x1 detailqos policy type : queuingqos queuing hdl : 0x00000001queuing_cookie :style : PWFQ num_q : 8queuing attr flag: NONE agg_weight : 0Agg Shaping :qos shaping flag: MAX_RATEmax rate/burst : 80000/16000


SSR PWFQ H-QoS on Hitchhiker qos policy PWFQ1-1 pwfq

rate maximum 50000queue 0 priority 0 weight 100queue 1 priority 1 weight 100queue 2 priority 2 weight 100queue 3 priority 3 weight 100queue 4 priority 4 weight 100queue 5 priority 5 weight 100queue 6 priority 6 weight 100queue 7 priority 7 weight 100!qos policy PWFQ1-2 pwfq rate maximum 50000queue 0 priority 0 weight 100queue 1 priority 1 weight 100queue 2 priority 2 weight 100queue 3 priority 3 weight 100queue 4 priority 4 weight 100queue 5 priority 5 weight 100queue 6 priority 6 weight 100queue 7 priority 7 weight 100!qos policy PWFQ2-1 pwfq rate maximum 50000queue 0 priority 0 weight 100queue 1 priority 1 weight 100queue 2 priority 2 weight 100queue 3 priority 3 weight 100queue 4 priority 4 weight 100queue 5 priority 5 weight 100queue 6 priority 6 weight 100queue 7 priority 7 weight 100!qos policy PWFQ2-2 pwfq rate maximum 50000queue 0 priority 0 weight 100queue 1 priority 1 weight 100queue 2 priority 2 weight 100queue 3 priority 3 weight 100queue 4 priority 4 weight 100queue 5 priority 5 weight 100queue 6 priority 6 weight 100queue 7 priority 7 weight 100


qos rate applied on L3a (1)



› PWFQ 中每个 circuit 最大可以分配 50M 带宽，但是 L3a node 中 qos rate maximum 定义为 40M 或 30M ， L4 node 中的 port 下最大可以分配 128M 带宽，因此 4 个 circuit ，每个可以获取 32M ，但是由于 100:2 和 200:2 在L3a 中限制了最大 30M ，因此剩余的 2M 分别分配给了 100:1 和 200:1 ，因此最终流量调度为 34M ， 30M ， 34M ，30M 。



› 将 L4 node port 下的 qos rate maximum 修改为 100M 。



› 如果在 L3a 上已经使能了 qos ，那么如果再尝试在 L3b 上配置 qos 的时候，会有 error 提示，但是命令还是可以配置：


Qos Weight & rate applied on L3a(1)

› 仅配置 qos weight 在 Cvlan level 。



› Analysis ：› 1. L4 node port 下 qos rate 为 80M ，因此 4 个 circuit compete 80M 资源，由于 Svlan 未配置 qos ，因此每个 Svlan 获取 40M 带

宽；› 2. 其次根据 qos weight 分配 Cvlan 的资源， (100:1):(100:2)=8:2 ，因此 100:1 获取 40M*8=32M ， 100:2 获取 40M*2=8M ；

(200:1):(200:2)=4:6, 因此 200:1 获取 40M*4=16M, 200:2 获取 40M*6=24M.



› 配置 qos rate 在 Cvlan 下



› 1. L4 node port 下 qos rate 为 80M ，因此 4 个 circuit compete 80M 资源，由于 Svlan 未配置 qos ，因此每个 Svlan 获取40M 带宽；

› 2. 其次根据 qos weight 分配 Cvlan 的资源， (100:1):(100:2)=8:2 ，因此 100:1 获取 40M*8=32M ， 100:2 获取40M*2=8M ； (200:1):(200:2)=4:6, 因此 200:1 获取 40M*4=16M, 200:2 获取 40M*6=24M.

› 3. 最后根据 Cvlan level 的 qos rate 限制带宽，由于 Svlan100 下未做限制，因此最终 100:1 获取 40M*8=32M ， 100:2 获取40M*2=8M ；而 Svlan200 下做了 rate 限制， 200:1 限制 15M ， 200:2 限制 20M ，都超出了第二步分配的带宽，因此最终 200:1 获取 15M ， 200:2 获取 20M 。


Queue Rate/Weight/PG Shaper Configed Simultaneously(1)

› 此例中， PG 1 Shaper 为 3.5M ， Queue 2 rate 8M ， Queue 3 rate 2M ， Queue 2:Queue 3= 3:7› 1. 首先查看 PG Shaper 发现只有 3.5M 的 traffic ，因此 Queue 2 和 Queue 3 Share 3.5M Traffic.› 2. 其次查看 Weight ，发现 Queue2 ： Queue3=3:7 ，因此 Queue2 ： Queue3=1.05M:2.45M› 3. 最后查看 Queue Rate ， queue 2 最大调度 8M ， queue 3 最大调度 2M ，因此最终 Queue3 能获取 2M ，剩余的 0.45M 被 Queue2

抢去，因此 Queue2 最终调度 1.5M 。


Queue Rate/Weight/PG Shaper Configed Simultaneously(2)


SSR QoS PRopagation

PropagationBasics


LRAN

2G3G4G

IP/MPLSConverged Aggregation

Mobile

Residential

Enterprise

IP/MPLSCore

Aggregation CoreAccess

PE

PEPE

PE

PEPE

PE

IP/MPLS Access

PEPE

PE

Propagation, IntroductionWhy propagation?

webH

VoIPH

VideoH

Packets for different services arrive at the system

How are the packets differentiated inside the system?

How do the packets keep QoS information when exiting the system?


Propagation, Introduction

Propagation is one method to map the PD QoS values for each packet.

What is propagation?

PD QoS bits are used internally for applying QoS related features

to the traffic.

Another method is marking which will be covered in later lessons.

VoIPH

External QoSInternal QoS

VoiPH

External QoS

210210

PacketPD H

210210

PacketPD H

210210

PacketPD H VideoH

webH

VideoH

WebH

Packets for different services arrive at

system

Packets for different services arrive at

system

Packets for different services arrive at the

system


Propagation, Introduction

210210

PacketPD H PacketH

› IP ToS or› 802.1p or› MPLS EXP

External QoSInternal QoS

PacketH

› IP ToS or› 802.1p or› MPLS EXP

External QoS

› Propagation: Defines mappings between external and internal packet priority &

drop-precedence values› Bits are translated and not copied

Command: propagate qos from <L2/L3>Command: propagate qos to <L2/L3>Note! Propagation is not Queue mapping!

What is propagation? IP

Ethernet

MPLS

IP

Ethernet

MPLS


Mapping

0

1

2

•••

6

7

7

6

5

•••

12

60

1

6

4

•••

0

2

› Mapping: is one to one relationship between extarnal QoS values and internal QoS values

7

6

5

•••

12

60

One to one mapping according to a scheme

Ingress translationEgress translation

Mapping schema

Possible values (8-64) for external

QoS markings

Possible values (8-64) for internal PD QoS

markings

•••

Mapping schema

Possible values (8-64) for

external QoS markings

•••

PacketPD H PacketH

Internal QoS

PacketH

External QoSExternal QoS

What is a mapping used with propagation?

One to one mapping according to a scheme

Oth

er Blo

cks

Default & Customized Mapping


Is propagation enabled by default?

Default Propagation

Is propagation enabled by default?

PacketPD H PacketH

Internal QoS

PacketH


It depends on propagation type:

IP, Ethernet or MPLS

It depends on propagation type:

IP, Ethernet or MPLS

It different for ingress or egress traffic.

It different for ingress or egress traffic.


IP IP

Default Propagation: IP

PacketPD H PacketH

Internal QoS

PacketH


By default: Ingress propagation is enabled for IP

By default: Egress propagation is disabled for IP

Note! Default propagation could be different depending on IPOS release

and the hardware platform


Default Propagation: Ethernet

PacketPD H PacketH

Internal QoS

PacketH


By default: Ingress propagation is

disabled for Ethernet

By default: Egress propagation is

disabled for Ethernet EthernetEthernet




Default Propagation: MPLS

PacketPD H PacketH

Internal QoS

PacketH


By default: Ingress propagation is

enabled for MPLS

By default: Egress propagation is

enabled for MPLS MPLSMPLS




Default Mapping SchemaWhich internal values are

mapped to external values?

PacketPD H PacketH

Internal QoS

PacketH


Which external values are mapped to internal values?

56

57

58

•••

6

7

0

1

2

•••

62

63

0

1

2

•••

62

63

•••

•••

?

?

?

•••

?

?

?

?

?

•••

?

?

0

1

2

•••

62

63

Default Mapping schema

Default Mapping schema

To what internal value is the external value 63 mapped?

To what external value is the internal value 63 mapped?


external QoS

Default mapping schema:

› Defined by the system

› Separate mapping schema for ingress and egress


external QoS

64 possible values for

internal QoS


Customized mapping

0

1

2

•••

6

7

7

6

5

•••

12

60

1

6

4

•••

0

2

› Default mapping: defined by the system

› Customized class maps: manually defined by the admin

› It’s possible to combine default and customized mappings

7

6

5

•••

12

60

Mapping according to a customized scheme

Ingress translationEgress translation

Mapping schema

Possible values (7-64) for external

QoS markings

64 Possible values for internal PD QoS

markings

•••

Mapping schema


external QoS markings

•••

Ingress Egress

PacketPD H PacketH

Internal QoS

PacketH


Mapping according to a customized scheme

Propagation: Where?


LRAN

2G3G4G

IP/MPLSConverged Aggregation

Mobile

Residential

Enterprise

IP/MPLSCore

Aggregation CoreAccess

PE

PEPE

PE

PEPE

PE

IP/MPLS Access

PEPE

PE

Propagation in Reference networkPropagation, where?

QoS PropagationQoS

Propagation

QoS Propagation

QoS Propagation

QoS Propagation

QoS Propagation


SSR New Feature in 12B

BGP BEST EXTERNAL(IPOS 12B)


› Standard Compliance– IETF Draft draft-ietf-idr-best-external

› Advertisement of the best external route in BGP

› Default– A path is a candidate for being a best external path only if it is identical to the best path in all

attributes as far as the MED› i.e. weight, local preference, as path length, MED

› Unconditional– If you want to remove default restriction, such that all paths are considered for computing the

best external path

Bgp best external

http://tools.ietf.org/html/draft-ietf-idr-best-external


AS2

AS1

R1 R2

R3

1.1.1.1/32 1.1.1.1/32

P1 P2

P11.1.1.1/32 P1* P2

P1

1.1.1.1/32 P1*

1.1.1.1/32 P1*

The ProblemThere two paths to 1.1.1.1/32, but R3 knows about only one.

It would be desirable to have R3 know about both the paths, if possible.


AS2

AS1 R1 R2

R3

1.1.1.1/32 1.1.1.1/32

P1 P2

P11.1.1.1/32 P1* P2

P1

1.1.1.1/32 P1* P2

P2

P2

1.1.1.1/32 P1* P2

R3 know about both the paths, once Best External is enabled.

Best external calculation

With Best External


› How to enable?[local]Ericsson(config-bgp-af)#advertise external

› How to debug?– debug bgp rib nexthop– debug bgp bestpath– debug bgp update

› Debug exampleAug 23 22:53:29: [0013]: %BGP-7-BESTPATH: 3.0.0.0/8 best (peer 100.1.42.2 nh 100.1.42.2) groupbest (peer 100.1.0.1 nh 100.1.11.2)Aug 23 22:53:29: [0013]: %BGP-7-BESTPATH: 3.0.0.0/8 new best (peer 100.1.0.1 nh 100.1.11.2) reason: larger local preferenceAug 23 22:53:29: [0013]: %BGP-7-BESTPATH: 3.0.0.0/8: path (peer 100.1.42.2 nh 100.1.42.2) is eligible for best external

operations


Unconditional adv[local]PE4#sh bgp route 3.0.0.0/8

BGP ipv4 unicast routing table entry: 3.0.0.0/8, version 9

Paths: total 2, best path count 1, best peer 100.1.0.1

Advertised to peer-groups: 1

iBGP

Advertised to non-peer-group peers: 1

100.1.42.2

150 3

Nexthop 100.1.42.2 (0), peer 100.1.42.2 (150.0.0.1), AS 150

Origin IGP, localpref 100, med 0, weight 100, external, best external

200 3

Nexthop 100.1.11.2 (3), peer 100.1.0.1 (100.1.0.1), AS 100

Origin IGP, localpref 120, med 0, weight 100, internal, best


Unconditional adv[local]PE3#sh bgp route 3.0.0.0/8

BGP ipv4 unicast routing table entry: 3.0.0.0/8, version 7

Paths: total 2, best path count 1, best peer 100.1.0.1

Not advertised to any peer

150 3

Nexthop 100.1.42.2 (2), peer 100.1.0.4 (100.1.0.4), AS 100

Origin IGP, localpref 100, med 0, weight 100, internal

200 3

Nexthop 100.1.11.2 (2), peer 100.1.0.1 (100.1.0.1), AS 100

Origin IGP, localpref 120, med 0, weight 100, internal, best

OSPF NSR (IPOS 12B)


From Gr to nsr

OSPF Graceful Restart

• Standard Based: RFC3623

• Restart/Switchover are noticeable by adjacencies

• Requires support from connected neighbours

• Not acceptable in PE-CE scenarios

• AKA “nonstop forwarding”

OSPF Nonstop Routing

• Proprietary Solution

• Don’t require any support from adjacencies

• => Don’t require standardization

• Require two RPSW cards

• LSDB are always in sync

• OSPF process is running on both cards

http://tools.ietf.org/html/rfc3623


› Performs non-stop routing across switch-over– Specific to OSPF– Specific to route processor (RP) switch-over– Specific to FULL neighbors

› Fully adjacent OSPF neighbors remain intact– Database does not need to be re-built

› Improvements– Does not need a helper like GR– Faster than OSPF graceful-restart (GR)

› Available in SEOS 11.1, now in IPOS 12.1

Nsr overview


› Prerequisites– Two operational RPSW cards in the

chassis– The RPSW cards are in synchronized

state[local]Ericsson#show redundancy rpsw --------------------------------- This RPSW is active---------------------------------STANDBY RPSW READY? : YES<SKIP>

– NSR is explicitly enabled under OSPF instance

– NSR state is Ready

Nonstop routing


› How to enable NSR?– [local]Ericsson(config-ospf)#nonstop-routing

› Example:Current configuration:

context local! router ospf 123 fast-convergence nonstop-routing area 0.0.0.0 interface SSR8020 passive

operations


› OSPF state with disabled NSR (default)[local]Ericsson#show ospf

--- OSPF Instance 123/Router ID 1.1.1.1 ---

Intra-Distance : 110 Inter-Distance : 110 Ext-Distance : 110 Type of Service : TOS-Type0 <SKIP>Nonstop-Routing : No NSR NSR Status : N/A Tunnel Shortcuts: No Redist Pending : No Forced SPF Count: 0

Area List (1 total):0.0.0.0

operations


› OSPF state with enabled NSR (active RPSW)[local]Ericsson#show ospf


Intra-Distance : 110 Inter-Distance : 110 Ext-Distance : 110 Type of Service : TOS-Type0 <SKIP>Nonstop-Routing : Yes DR NSR Status : Ready NBR NSR Status: : Ready LSDB NSR Status : Ready Tunnel Shortcuts: No Redist Pending : No Forced SPF Count: 0


operations


› OSPF state with enabled NSR (standby RPSW)[local]standby#show ospf


Intra-Distance : 110 Inter-Distance : 110 Ext-Distance : 110 Type of Service : TOS-Type0 <SKIP>Nonstop-Routing : Yes DR NSR Status : Ready NBR NSR Status: : Ready LSDB NSR Status : Ready Tunnel Shortcuts: No Redist Pending : No Forced SPF Count: 0


operations


› Separate OSPF NSR thread[local]Ericsson#show process ospf thread-info

NAME STATE PR FLAG UTIME STIME CTX-SW<SKIP>nsr-recv 0 20 4202560 0.00 0.00 11

› Debug– [local]Ericsson#debug ospf nsr– [local]Ericsson#debug standby ospf nsr

Aug 23 19:41:02: [0001]: %OSPF-7-NSR: [ACTIVE] OSPF-123: Re-synchronize to the standby [ospf_nsr_resync_to_standby]Aug 23 19:41:02: [0001]: %OSPF-7-NSR: [ACTIVE] OSPF-123: Resend interface DR/BDR informationAug 23 19:41:02: [0001]: %OSPF-7-NSR: [ACTIVE] OSPF-123: Resend FULL neighborsAug 23 19:41:02: [0001]: %OSPF-7-NSR: [ACTIVE] OSPF-123: Resend LSDBAug 23 19:41:02: [0001]: %OSPF-7-NSR: [ACTIVE] OSPF-123: NSR enabledAug 23 19:41:02: [0001]: %OSPF-7-NSR: [ACTIVE] OSPF-123: tlv_type Cleanup Request tlv_len 20 [ospf_nsr_cleanup_sent]Aug 23 19:41:02: [0001]: %OSPF-7-NSR: [ACTIVE] OSPF-123: INTF Sync Queue depleted: SESSION_DR_NSR_READYAug 23 19:41:02: [0001]: %OSPF-7-NSR: [ACTIVE] OSPF-123: 0 intf TLVs sentAug 23 19:41:02: [0001]: %OSPF-7-NSR: [ACTIVE] OSPF-123: NBR Sync Queue depleted: SESSION_NBR_NSR_READYAug 23 19:41:02: [0001]: %OSPF-7-NSR: [ACTIVE] OSPF-123: 0 nbr TLVs sentAug 23 19:41:02: [0001]: %OSPF-7-NSR: [ACTIVE] OSPF-123: Sent lsdb TLVs led by Router:1.1.1.1[1.1.1.1]Aug 23 19:41:02: [0001]: %OSPF-7-NSR: [ACTIVE] OSPF-123: LSDB Sync Queue depleted: SESSION_LSDB_NSR_READY

operations


› OSPF NSR takes effect only during RP switch-over– Use graceful-restart for restart scenarios on one single RP

› Only FULL neighbors remain intact after switch-over› GR-helper will be aborted after switch-over› OSPF NSR is not supported on sham links› Non-OSPF routes might flap

Nsr issues & limitations

BFD(IPOS 12B)


› Bidirectional Forwarding Detection– Simple hello protocol to detect link failures

› IPv4-only› Single-Hop› No LAG support› BFD session will be not initialized unless it has a configured client

– BFD Clients are OSPF, PIM, BGP, etc.

Bfd


› Configurable timer intervals (ms)– 10, 100, 1000, 20, 200, 30, 300, 50, 500, 1000 … 6000 (step 1000)

› The configurable intervals are based on NPU base intervals – Base intervals is 3.3, 10, 100, 1000– Example: 500 ms interval mean 5x100 ms internal events for NPU before sending single

packet– BFD is using common OAM/keepalive NPU framework

› Other possible users of the framework: VRRP, CFM

Bfd timers

PBR(IPOS 12B)


› Scope– Redirect to next hop IP address

› Up to 8 non-default classes plus default› NH - Up to 8 IP addresses in priority order

– Redirect to GRE tunnel› User can specify the GRE peer IP address and the cpntext of that IP address

– Drop Traffic› All traffic classified to the class with dtop action should be dropped and ICMP (Destination

Unreachable, Communication Administratively Prohibited) generated– Ignore Traffic– LAG support

› Functionality can be applied to the ingress direction only

pbr

Ldp extension for inter-area lsp’s(IPOS 12.1)


› Standard Compliance– IETF RFC5283

› LDP Extension for Inter-Area Label Switched Paths (LSPs)

› Not in original roadmap for 12.1– Was implemented as an enhancement for FOA customer

› Don’t require any configuration› Don’t modify default behavior› Don’t introduce performance penalty

overview

http://tools.ietf.org/html/rfc5283


Without ldp extension

› Operator MUST configure route-leaking for /32 routes to be able to establish e2e LDP LSP’s

– In 2000 nodes network each L1 will need to store 2000 /32 prefixes + intra-routes


With ldp extension

› Operator should configure route-leaking for summarized subnets to be able to establish e2e LDP LSP’s

– L1 area will handle intra-route + route-leaking summary route– Will work with default route (not recommended)

MPLS OAM(IPOS 12B)


› Standard Compliance– LSP Ping: IETF RFC4379

› Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures– IETF RFC5085

› Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires

› Scope– Injecting the MPLS OAM packets into the Ingress PFE– Support LSP ping, LSP traceroute on LAG LSP’s– Support VCCV ping on VLL PW Traversing on LAG LSP– Support VCCV ping on PW configured with LAG AC

Mpls oam

Control Plane Protection

(IPOS 12B)


› IPOS 12.1 introduce support for control plane protection AKA rate-limiters (phase 1)

– Primary objective is to protect Line Card Processor (LP) from overload by punted traffic› The overload of LP means dropped packets, missed hellos, etc.

– Secondary objective is to protect RPSW CPU

› The rate-limiters are applied to the punt path per PFE– For each line card different rate-limiter profiles

› Depends on the number of PFE’s› Depends on the type of LP

– Different queues for different traffic type– There is no publicly available IPOS command to check punt drops and rate-limiters

Control plane protection


Punt path rate limiters


Punt Class Protocol Priority

L2 Control Traffic LACP, BPDU, PTP High

L3 Control Traffic ARP High

ISIS High

IP Control Traffic PIM, IGMP High

VRRP High

BFD High

ICR High

Local IP traffic ICMP Medium

OSPF High

RSVP High

TCP Medium

UDP Medium

Other Medium

IP Dropped Traffic NO_ROUTETTLDFACL DENY

Low

Copp - cont

In total punted traffic cannot use more than 50% of LP


SSR New Feature in 13A

Port Mirroring(IPOS 13A GA)


› Port MirroringPort mirroring helps an operator troubleshoot network problems by allowing him to create a copy of all the packets that either ingress or egress a specified physical port and send those packets to a mirror destination. Traffic at the mirror destination can be analyzed using a network analyzer.

› Mirror DestinationThe following mirror destinations are supported in SSR Release 13A:

› Local Destination- Physical Ethernet Port- Layer 2 Service instance

› Remote Destination- Pseudowire instance

Port Mirroring: Overview


Port as a destination:The following example configures Ethernet port 1/1 as mirror destination dest1:[local]Ericsson(config)#port ethernet 1/1[local]Ericsson(config-port)#forwarding destination dest1

Pseudowire as a destination:The following example configures pseudowire instance 1 as mirror destination dest2:[local]Ericsson(config)#pseudowire instance 1[local]Ericsson(config-pw-instance)#pw-id 1[local]Ericsson(config-pw-instance)#peer-profile peer-prof-1[local]Ericsson(config-pw-instance)#forwarding destination dest2 L2 Service Instance as a destination:The following example configures L2 service instance 4 as mirror destination dest3:[local]Ericsson(config)#port eth 1/2[local]Ericsson(config-port)#encap dot1q[local]Ericsson(config-port)#service-instance 4[local]Ericsson(service-instance)#match[local]Ericsson(si-match)#default[local]Ericsson(service-instance)#forwarding destination dest3

Port Mirroring: ConfigurationSTEP 1: CONFIGURE A MIRROR DESTINATION


The following example creates a mirror policy, mirror-1, and configures its mirror destination and rate limiting. Since no maximum length is configured, the entire frame is mirrored.[local]Ericsson(config)#mirror policy port mirror-1[local]Ericsson(config-policy-mirror)#destination dest1[local]Ericsson(config-policy-mirror)#rate 10000 burst 1000

The following example only mirrors headers by limiting the maximum length of the mirrored traffic to 20 bytes:[local]Ericsson(config)#mirror policy port mirror-3[local]Ericsson(config-policy-mirror)#destination dest3[local]Ericsson(config-policy-mirror)#rate 10000 burst 1000[local]Ericsson(config-policy-mirror)#maximum-mirror-length 20

Port Mirroring: ConfigurationSTEP 2: configure a mirror policy


The following example binds mirror policy mirror-1 to the source Ethernet port for ingress traffic. mirror-1 is configured to send mirrored traffic to dest1, so Ethernet port 1/10's ingress traffic is mirrored to dest1:[local]Ericsson(config)#port eth 1/10[local]Ericsson(config-port)#mirror policy mirror-1 in

The following example uses a single mirror destination to receive multiple mirrored ingress traffic streams. Source tags are configured to distinguish between the streams at the destination end:[local]Ericsson(config)#port eth 1/3[local]Ericsson(config-port)#mirror policy mirror-1 in source-tag 300

[local]Ericsson(config)#port eth 1/4[local]Ericsson(config-port)#mirror policy mirror-1 in source-tag 400

[local]Ericsson(config)#port eth 1/5[local]Ericsson(config-port)#mirror policy mirror-1 in source-tag 500

Port Mirroring: ConfigurationSTEP 3: Bind a policy to a source port


› 128 bindings of mirror policy to source port per line card.

› 4000 bindings of mirror policy to source port per SSR system.

› 1000 mirror policies per chassis.

› 1000 mirror destinations per chassis.

› Mirrored traffic counts against the total forwarding capacity of the PFE.

Port Mirroring: KPI


› Ingress port mirroring replicates all incoming traffic including:– Control traffic received by the source port.– Multicast traffic.

› Egress port mirroring replicates all outgoing traffic including:– Control traffic send to the traffic manager. Even frames that are dropped by the traffic manager in the source stream of traffic are

mirrored to the mirror destination.– Locally sourced traffic from the RPSW controller card and Smart Services Card (SSC).– Multicast traffic.– Frames that have been fragmented during egress.

› Mirrored frames are:– Subject to the QoS features applied to the mirror destination.– Counted as part of the normal transmit/drop statistics supported on the mirror destination.

› Performance Considerations:– Port mirroring has a significant impact on system performance, affecting both the source port and mirror destination ends.– The rate limit function in the mirror policy (rate command) mitigates some of the performance impact of mirroring because it is invoked before the packet

replication. It is to be noted that the rate command itself requires several lookups before a transmit/drop decision is made. Therefore, there is a performance degradation even when all mirror traffic is dropped.

Port Mirroring: SOME NOTES

QoS on NGL2(IPOS 13A)


› Introduce the support of QoS for NGL2 (new implementation of L2 services – XC and VPWS)

› QoS supported:– Policing– Metering– PWFQ– WRED– Propagation

› There’s no ACL supported yet, so it must be based on QoS fields through propagation

QoS on NGL2


NGL2 Qos packet flow

Execute“propagate from”

Ingress PFE

Egress PFE

Apply policingpolicy

Apply ingressrewrite rules

Apply meteringpolicy

Apply egressrewrite rules

Execute“propagate to”

TM functions(queuing, shaping, WRED)


› Propagation mix between L2 and L3 circuits:– In 13A, it will be non user-friendly behavior.dot1q profile DOT1Q-IN propagate qos from ethernet <== without 'inner' key word

port ethernet 10/1 encapsulation dot1q dot1q pvc 100 encap 1qtunnel dot1q pvc 100:11 profile DOT1Q-IN <== PD-Qos is set from inner most tag on L3 circuit

port ethernet 10/2 encapsulation dot1q service-instance si10 match dot1ad 20:20 <== PD-Qos is set from outer tag on NGL2 circuit. profile DOT1Q-IN

› Targeted to be solved in 14B with the feature called QoS propagation to make the keywords inner, outer, both mandatory.

QoS on NGL2


› Scaling:– Support up to 256K circuits with 3 QoS bindings (1 policing,

1 metering, 1 PWFQ) – system- wide.

› Limit to keep in mind:– When a push or swap is done in a service-instance, the new Ethernet header has the dot1p

bits set to 0.– L2ACL is coming in 14A– Bulkstat is not currently supported on NGL2, working on short term workaround.

QoS on NGL2

IPv6 unicast infra(IPOS 13A)


› What is supported for IPv6 infra from 13A?– IPv6 unicast forwarding (including link local and ND)– IPv6 filter ACL (no support for counter and logging keywords)– IPv6 policy ACL– QoS for IPv6 traffic (policing, metering, PWFQ, WRED, propagation)

› What changed?– From 32K circuits down to 24K circuits support per PFE, due to new counter needs for IPv6

on NP4.

IPv6 unicast infra


› Limit to keep in mind:– Maximum 7,000 ND neighbors per linecard

– BFDv6 is coming in 13B– VRRPv3 is coming in 14A– IPv6 PBR is coming in 14A

IPv6 unicast infra


SSR New HW in 13B


4x10GE/2x10GE+20x1GE (BNG) Line card

› Designed to support the BNG feature set on SSR› Hardware is based on field proven SmartEdge ASICS integrated in

SSR system architecture› 40Gbps throughput

– Configurable as either 4 ports of 10GE or 2 ports of 10GE and 20 ports of 1G

– Use any SSR SFPs or XFPs› Including DWDM fixed wavelength

› Low Power Consumption– 480W Maximum

› High Scale– Support for 96K subscribers

› NEBS, RoHS 6 compliant


1x100GE/2x40GE Line card› New SSR line card designed for High Bandwidth Uplinks › 100 Gbps throughput

– Configurable as either 1 port of 100GE or 2 ports of 40GE› Industry standard form factor Ericsson CFP optical plug-ins are

supported– Allows separate sparing of line card and high value optics– LR-4 with 10km reach in SSR 13B– Future support for DWDM and OTN

› Low Power– Maximum 400W– CFP Power – 100G 24W; 40G 8W

› NEBS, RoHS 6 compliant


SSR BNG 13B


Line Card for BNG ( Cerberus/PPA3LP)

› BNG Features – PPP Dual Stack– L2TP LAC– CLIPSv4– Advanced RADIUS Services : RSE, DQP– IPv4/IPv6 services : Portal redirection (Http), PBR, ACL, LI, Mirroring– Hierarchical Policing/Metering, Marking– PWFQ – 8 CoS queues per session/512K queues per card– Inline CGNAT44

› Other features – GRE tunneling– LAG – IPv4/IPv6 Routing, 6PE, 6vPE, – L2VPN/VPWS, VLAN XC– BGP L3VPN– IPv4 Multicast (IGMP, PIM) – BFD (v4/v6)– VRRP


BNG card architecture

iPPA3

ePPA3

ePPA3

20G

20G

› 40Gbps Full Duplex : 20Gbps simplex per PPA3 ASIC, Ingress PPA / Egress PPA

› Two PFE complexes (iPPA3+ePPA3) with physical ports (10GE or 1GE) statically mapped to one of the PFEs– PFE0 : GE ports 1 to 10 / 10GE port 21 and 23– PFE1 : GE ports 11 to 20 / 10GE port 22 and 24

› Local Processor (LP) : Proxy IPC communication between RP (IPOS) and each PPA NPU– No FABL running on LP as opposed to other Line Cards running FABL (L2L3, SSC)

PPA3 : Packet Processing ASIC 3rd Generation | FAA : Fabric Access ASIC | LP : Local Processor | PP : Packet Processor

iPPA3

FAA

LP

RPSW

CP : IPC CommunicationIPOS

ALSW / SW

DP: Fabric Communication

PFE1

PFE0I/O -10G

E / 1G

E

XF

PS

FP

XF

PS

FP

SF

PS

FP

SF

PS

FP

SF

PS

FP

SF

P

I/O -10G

E / 1G

E

XF

PS

FP

XF

PS

FP

SF

PS

FP

SF

PS

FP

SF

PS

FP

SF

P

11....

202224

1....

102123


BNG card architecture (Cont)SW configuration

›Two card modes with selection at card’s configuration time

# card 1-10ge-20-4-port {1-10ge | 10ge}[local]SSR(config)# card 1-10ge-20-4-port 1-10ge 1 [local]SSR(config-card)# no shutdown[local]SSR(config)# port ethernet 1/{1..20} ! these are 1GE ports[local]SSR(config)# port ethernet 1/{21,22} ! These are 10GE ports[local]SSR(config)# card 1-10ge-20-4-port 10ge 2 [local]SSR(config-card)# no shutdown[local]SSR(config)# port ethernet 2/{21..24}

›Changing the card mode requires reconfiguration of the card and a card reload

[local]SSR(config)#no card 4-10ge-20-1ge 1-10ge 1 [local]SSR(config)#card 4-10ge-20-1ge 10ge 1 [local]SSR(config-card)#no shutdown[local]SSR(config-card)#commit


BNG Card

FAA

BNG card architecture (cont)Packet Walk thru (Ingress)

iPPA3

ePPA3

ePPA3

I/O

(10GE

/1GE

)

20G

20G

I/O

(10GE

/1GE

)

L2-L3 Line Cards

FAA

Smart ServiceCards

FAA

Packet

Packet scheduled by FAA to the Switch Fabric (VoQ) to destination card (BNG card, L2L3 card or SSC)

Fabric transmit packet to destination card based on Fabric header

Packet received by destination card (FAA) and egress features applied on

PP (ACL, Metering, PWFQ, Encapsulation…)

PP

SS

S

SS

S

S S

Switch Fabric

iPPA3

FAA

Packet

Packet

› BNG card can send traffic to any destination card : L2L3 cards (40x1GE, 10x10GE, 1x100/2x40GE), BNG card, SSC card– Steering to SSC applications in later releases with Multi-application - BNG collocation with Apps in SSR 14B and Beyond.

› Efficient 2-stage multicast replication : Switch Fabric, ePPA


LP

Packet received by 1 of the 2 Ingress PPA, features applied: ACL, Policing,

uRPF, FIB lookup


BNG Card

FAA

BNG card architecturePacket Walk thru (Egress)

L2-L3 Line Cards

FAA

Smart ServiceCards

FAAFabric transmits packet to

destination BNG card based on Fabric header

Packet received by Ingress Line Card and features applied by PP : ACL,

Policing, uRPF, FIB lookup

Packet scheduled by ingress FAA (VoQ) and sent to Switch Fabric with Fabric

header

PP

SS

S

SS

S

S S

Switch Fabric

iPPA3

ePPA3

ePPA3

I/O

(10GE

/1GE

)

20G

20G

I/O

(10GE

/1GE

)

iPPA3

FAA

Packet received by the EgressPPA and egress features applied (ACL,

Metering, PWFQ, Marking, Encapsulation …)

Packet received by FAA from Switch Fabric and transmitted to

destination ePPA

Packet

PacketPacket

LP



BNG Line card ScalingLine Card Level Per PFE

Single Stack 96K (64K subs with PWFQ + 32K subs without queues) 48K (32K subs with PWFQ + 16K subs without queues)

Dual Stack 48K DS subscribers 24K DS subscribers

FIB IPv4: 4 Million @ /24IPv6: 2.5 Million@ /64

NGL2 • 96K VLANs• 48K VLAN X-Connects• 96K VPWS

• 48K VLANs• 24K VLAN X-Connects• 48K VPWS

BFD • 4K IPv4 BFD sessions with 100ms interval• 400 IPv4 BFD sessions with 10ms interval

• 2K IPv4 BFD sessions with 100ms interval• 200 IPv4 BFD sessions with 10ms interval

Multicast 32K IGMP Groups2K OIFs per IGMP Group


BNG System Scaling

• 480K Single Stack• 480K Dual Stack

• 32K L2TP Tunnels

PRA


BNG System Bring-up Performance

› Bring up rate measured with– RADIUS Authentication & Accounting – ACLs, QoS and PWFQ Queuing enabled for all subscribers

Single Stack Subscribers

Dual Stack Subscribers Note

1 Line Card 350/sec 280/sec Bring-up Rate limited by BNG Line card capability

2 Line cards 600/sec 350/sec If VP-CG is used for PWFQ on 10G ports the Bring-up rate will be reduced by 10%


SSR BNG card and SE BNG Throughput Performance Comparison

Frame Size (Bytes)

IPv4 Throughput (%) IPv6 Throughput (%)

SE* SSR SE SSR

64 96 83**

78 46 52

128 100 100 67 74

220 100

256 100 100 100 100

1518 100 100 100 100

› Measurement done with no features (Vanilla IP forwarding)› Local context, no Dot1q PVC, bind interface › Using /24 IPv4 Prefixes and /64 IPv6 Prefixes

* SE based on 20G through one linecard & SSR based on 40G though the BNG Linecard

**: Target is to improve this to around 94%


Integration with 40G/100G Transport/Core

ACCESSBNG CARD

40G

100G

Edge/CoreAggregation

10G

40G CardMode

100G Card mode

40G

10G

10G

10G

› Interworking between BNG card for subscriber termination (PPP, L2TP LAC, CLIPS) and L2L3 cards for uplink– L2L3 cards can forward subscriber traffic to/from uplink – including L2TP traffic towards remote LNS– Subscriber sessions are processed on BNG access card and can terminate into regular or vpn context with L2L3 card as MPLS

uplink


New compared to SmartEdgeCLI - qos

› SSR QOS policies (Metering, Policing, PWFQ, Congestion Avoidance map), QoS Overhead profile will have an additional keyword to specify which type of line card they apply to.

[local]Ericsson(config)#qos congestion-avoidance-map pwfq-map pwfq card-family 2[local]Ericsson(config-congestion-map)#queue 0 red default min-thres 30 max-thres 5200 probability 16[local]Ericsson(config-congestion-map)#queue 0 red profile-1 dscp cs7 min-thres 140 max-thres 13000 probability 34[local]Ericsson(config-congestion-map)#queue 2 red default max-thresh 5200![local]Ericsson(config)#qos policy PWFQ-POLICY pwfq card-family 2[local]Ericsson(config-policy-pwfq)#num-queues 4[local]Ericsson(config-policy-pwfq)#congestion-map pwfq-map[local]Ericsson(config-policy-pwfq)#rate maximum 50000[local]Ericsson(config-policy-pwfq)#queue 0 priority 0 weight 100[local]Ericsson(config-policy-pwfq)#queue 1 priority 1 weight 70[local]Ericsson(config-policy-pwfq)#queue 2 priority 1 weight 30

“card-family type 2” is required for BNG cards.

If nothing specified, by default these policies

apply to the L2L3 cards


New compared to SmartEdgeCLI - Mirroring

› Configuration of mirroring on SSR uses new Mirroring policy› SSR L2L3 cards support only port mirroring. Mirroring policy applied at port level and mirrors entire

physical port traffic

! Create mirror policy mirror-1 and configures its mirror destination[local]Ericsson(config)#mirror policy port mirror-1[local]Ericsson(config-policy-mirror)#destination dest1[local]Ericsson(config-policy-mirror)#rate 10000 burst 1000

! Bind the mirror policy mirror-1 to the source Ethernet port for ingress traffic[local]Ericsson(config)#port eth 1/10[local]Ericsson(config-port)#mirror policy mirror-1 in

! Configure an ethernet port as mirror destination dest1[local]Ericsson(config)#port ethernet 4/1[local]Ericsson(config-port)#mirror destination dest1

› SSR BNG card support circuit level mirroring. Mirroring policy is applied at circuit level (PVC or Sub) and mirrors only the specified circuit traffic

›New VSA – 214 “Mirror_Policy” introduced

› Limitations : ›no support for “rate” option for BNG card›No support for mirror destination under Pseudowire instance


New compared to SmartEdgeLogging

› INFO messages will not be displayed on terminal or console. They are still logged in the logging buffers and sent to syslog servers as before.

› Logging level for a few messages is changed for ex: Port Up/Down message from INFO to NOTICE category

› New Format:

SSR: Nov 6 16:27:59: {6/LP}: %PPAINFRA-6-ISTART_INFO: 8f570d7f/0000000004/728700000:06/00/IPPA/EU00:Ready to receive packets SE:Nov 28 14:42:38.483: %PPAINFRA-6-ISTART_INFO: 2720ec7e/0000000001/664600000:01/IPPA/EU00:Ready to receive packets

› NV log is not available on SSR› ISP Log format changes due to control cards and slot numbering etc.› Syslog Server: No Change

{line-card number/LP}

is added to the logs

“00” or 01” indicates the

PPA complex on the card


SSR Unified LAGULAG covers both Access and core use cases

LACP

Switch

Card 4

Card 5

LACP

Card 3Card 7

Card 6

Card 1

Card 2

LACP active

LACP standby

Router/ LSR

Dynamic subscriber ccts

(PPP, CLIPS)

LACP

Switch

Hitless LAG : circuits are replicated with either packet hashing or circuit hashing (configurable)

Economical LAG : circuits are non-replicated with either packet hashing or circuit hashing (configurable)

Hitless LAG : circuits are replicated with either packet hashing or circuit hashing (configurable)


Pre-13B SSR Unified LAGThis is LAG Level1 circuit, it is enabled by default and applies to traffic to/from circuit binding “foo”.Traffic is load-balanced on all constituent links of the LAG based on L3 / L4 tuple hashing (packet hash)To change the default : “no load-balance”

Circuit PVC 200 (Level2 circuit) is by default created on all constituent ports/cards but traffic Tx is “link-pinned” or circuit hashed to a given physical port constituent. Traffic only egress from that “home” physical port/card

Circuit PVC 100 (Level2 circuit) is by default created on all constituent ports/cards and traffic is load balanced on constituent links based on L3/L4 tuple hashing (packet hash)

› Introduced in SSR 12B for L2L3 cards[local]SSR(config)#link-group LAG [local]SSR(config-lag)# load-balance[local]SSR(config-lag)# bind interface if-1 context1

[local]SSR(config-lag)# dot1q pvc 100[local]SSR(config-dot1q-pvc)# bind interface if-1 context2

[local]SSR(config-lag)# dot1q pvc 200 link-pinning[local]SSR(config-dot1q-pvc)# bind interface if-1 context2

[local]SSR(config)# port ethernet 4/1[local]SSR(config-port)# link-group LAG[local]SSR(config)# port ethernet 5/1[local]SSR(config-port)# link-group LAG

› Link-Group functional behavior– All circuits are always created (replicated) on all constituent links– By default packet based hashing (L3 or L4 tuple) for a circuit unless circuit is configured with “link-pinning” option (a.k.a circuit hashing)– “Link-pinning” or circuit hashing useful for egress QoS features accuracy : TM (PWFQ), Metering

› Without link-pinning, PWFQ, Metering applied on all constituent links (N links).› Circuit gets N x Shaping/Metering Rate


13B Unified LAGBNG Subscriber use cases

› SSR 13B adds optional keywords for subscribers use cases

– New options “economical” and “link-pinning” for BNG card based LAG at LG level[local]SSR(config)#link-group LAG [economical | link-pinning]

– Economical LAG with L1 and L2 circuit level options[local]SSR(config)#link-group LAG economical

[local]SSR(config-lag)# load-balance

[local]SSR(config-lag)# dot1q pvc 100 encapsulation multi [replicate] [load-balance]

This option dictates how the circuits are created on constituent links/cards :

• Economical : circuits are created on a single link/card – they are not replicated

• Link-pinning : circuits are created/replicated on all constituent ports/cards (similar to pre-13B LAG) and by default circuit hashed

On an Economical LAG, L2 circuits are by default created on a single link (non-replicated) and circuit hashed :

• “replicate” : Individual non-subscriber circuits can be replicated on all active ports/cards

• “load-balance” : replicated circuit is L3/L4 tuple packet hashed and load balanced across all links


13B Unified LAG (Cont)BNG Subscriber use cases

› SSR 13B adds optional keywords for subscribers use cases

– “Link-pinning” LAG with L1 and L2 circuit level options[local]SSR(config)#link-group LAG link-pinning

[local]SSR(config-lag)# load-balance

[local]SSR(config-lag)# dot1q pvc 200 [load-balance]

On a “link-pinning” LAG, all L2 circuits are replicated across all active ports/cards with circuit hashing

• “load-balance” : replicated circuit is L3/L4 tuple packet hashed and load balanced across all links

• Exception is L1 circuit which is by default in “load-balance” mode – can be changed to circuit-hash

› “load-balance” keyword for L1 or L2 circuit– This dictates the circuit has to use packet-hashing L3 or L4 depending on knob “service load-balance link-group {layer-3|layer-4}”

– Packet-hashing : packets are sent on TX (egress) on all constituent ports as opposed to circuit-hashing where packets always egress from the a single “home” port

Notes : - “service load-balance link-group source-only” will use only source IP address of packet for hashing the flow into one

constituent link- Applies only to L2L3 cards, BNG card always uses source/destination tuple (L3 or L4) for hashing algorithm


13B Unified LAG (CONT)BNG Subscriber use cases

› “Link-pinning” LAG– Supported on BNG cards only – it is a superset of SSR12B Default LAG– Subscriber circuits (PPP, CLIPS) which are dynamic circuits are always “link-pinning” (circuit hashing) and there is no option to

do “load-balance” for the individual subscriber circuits› Only parent circuit VLAN can be “load-balance” (packet hashing)

› “Economical” LAG– Supported on BNG cards only - *Not* supported on L2L3 cards– PWFQ on 10G Economical LAG uses VPCG which is not supported on Economical LAG– This is Hitfull LAG and when Link/Card goes down, may experience traffic drop or subscribers sessions going down depending

on :› Number of subscribers per port/PFE/card› PPP subscriber keepalive timers and retries (session timeout)

– Subscriber circuits (PPP, CLIPS) which are dynamic are always link-pinned and there is no option to do “load-balance” for the individual subscriber circuits

› Only parent circuit can be “load-balanced”

› SSR12B Default LAG – Supported by L2L3 card and BNG card– On BNG card, if using Default LAG then subscriber encapsulation (pppoe, multi) is not supported -> use “Link-pinning” or

“Economical” LAG for subscribers

› LAG cannot span different cards/NPU types, e.g cannot do LAG spanning over an L2L3 card and a BNG card


› CLIPS Dual-Stack› DHCPv6 Relay› L2TP LNS› Separate v4/v6 counters› Acct-Session-Id formatting tweak › L2TP Reserved bits RFC compliance› Non-DHCP CLIPS

BNG features on 14A / IPOS13.2


Is the FAP on cerberus same as NP4 ? Yes , Dune FAP100 (Petra B)

Is there a link between IPPA & EPPA ? If yes what is capacity ? Yes there is a link available from EPPA to IPPA(unidirectional) . The capacity of that link is 10G.

The slides state that there is a 2-stage multicast replication procedure in place.What if the packets need to replicated to go out through ports 1, 2, 10, 11 on slots 2 and 3 ? Shouldn’t that result in a 3-stage replication of the packets ( fabric, egress FAP, ePPA ) ?

Yes, that’s possible. eFAP will do the replication as well if the outgoing ports are on different pfe’s on the same line card

For single stack subscribers, the KPI numbers stand at 64K (max) with pwfq, and 32K without pwfq.Can that be extended to 64K+ subs ( with pwfq ) and no other subs on the same LC ?For ex : is it possible to have only 70K subs (with pwfq) and no other subscribers on a LC ?

That is not possible , the limitation for numbers of subs that can have pwfq comes from that the limitation with the number of queues available on the line card. 8 CoS queues per session/512K queues per card so that comes out to be 64k subs with pwfq.

Questions


For circuit-hashed LG, what are the parameters that will be used to decide the egress physical circuit from the constituent circuits of the LG ?

Parameter used is spg_id . You can find the spg_id on “show ism circuit <lg handle> detail”You can also see the port mapping for that spg_id via the command “sh card 7 ppa link-group spg-table”

Why is the bring up rate not linear when you have more than 1 line card ? AAA,RCM and ISM are the bottlenecks. Even though more line cards are used the provisioning for circuits and features are still

being done by the same above 3 processes.

Slot numbering for the ports ? For 1G ports, slot numbering is 1-20 , left to right same as Hitchhiker card

For 10G port, its 21-24, top down.

Why is the throughput for 64 byte IPv4 packets less than SE ? Please refer EV 201569

Are there any bring up rates numbers for subs terminating on LAG ? No, KPI team has not done any testing for bring up rates with subs terminating on LAG. They are planning to use scripts in the

future to get this measurement.

Questions


If a packet needs to go from a subscriber circuit on port 1 to core link on port 12 on the same LC, would that include traversal through the fabric ? Or will there be a short-circuit mechanism between the iFAP and eFAP on the LC ? ( something similar to short-circuit between PMAs on PPA ) ?

It will have to go through the fabric. There is one special case if you are using link-group where if the traffic is received on eppa which is for a circuit homed on ippa then the packet is forwarded via the 10G link from eppa to ippa.

Is LI supported and tested on PPA3LP ? Yes , same as SE.

Separate memory for PPA ? Yes, PPA has separate DDR which is 2G and also TCAM

What is the use of load-balance option on link-pinning LAG ? Load balance option on link-pinning LAG is used for non-subscribers circuits.

Questions


SSR IPv6 in Access Network


ISP-operated model

Provisioning Server

BNG

CPE

ER

IPv6 IPv6

Provisioning Server

IPv6 IPv6

PPP

DSLAM

Access Provider Network

Service Provider Network

Both networks owned and operated by the same provider.

Dual Stack

Dual Stack

Ethernet Access


Wholesale model

Provisioning Server

BNGLAC

ERLNS

Provisioning Server

IPv6IPv6

L2TPv2PPP

DSLAM

IPv6

Access Provider Network

Service Provider Network

CPE

IPv4

Ethernet Access

The networks owned and operated by different providers.

Dual Stack

Dual Stack


PPPoE with DHCPv6-PDSSR IPv6 in Access Network


PPPOE and LCP

AAA Server

BNG

PPP ServerPPP client

PPPoE - discovery LCP - configuration

DSLAM

IPv6

CPE

PPPoE Discovery

LCP Configuration


PAP/CHAP and IPV6CP

AAA Server

BNG


authentication

PAP/CHAP - authentication IPv6CP - Interface ID

DSLAM

IPv6

CPE

PAP/CHAP Authentication

/64

Interface ID

/64

Interface ID

PPP tunnel


NDP (RS/RA) in PPP

AAA Server

BNG


/64

prefix

NDP (RS/RA) - /64 prefix on CPE

DSLAM

IPv6

CPE

/64

prefix

PPP tunnel


DHCPV6 Prefix delegation

DHCPv6 Server

Delegating Router

Requesting Router

/48/64

2001:DB8:FF00::/482001:DB8:FF00:2::/64

2001:DB8:FF00:1::/64

network prefix

RS/RA - /64 prefix on PCDHCPv6 - DNS, domain list

DSLAM

IPv6

CPE

DHCPv6-PD - /48 prefix, DNS, domain list

/48

2001:DB8:FF00::/48

BNG

PPP tunnel


PPPoE

LCP

PAP/CHAP

IPv6CP

NDP (RS/RA)

DHCPv6-PD

RADIUS

DHCPv6 RelayNDP (RS/RA) + DHCPv6

IPv6 Address Allocation

Interface ID

IPv6 Prefix (CPE)

Delegated IPv6 Prefix

Authentication

Configuration

Discovery

IPv6 CPE BNG AAA

DHCPv6


IPv6oE with DHCPv6-PDSSR IPv6 in Access Network


IPv6oE with NDP (RS/RA)

BNG/64

prefix

NDP (RS/RA) - /64 prefix on CPE

DSLAM

IPv6

CPE

/64

prefix

DHCPv6 Server

Interface ID EUI-64


DHCPV6 Prefix delegation

DHCPv6 Server

Delegating Router

Requesting Router

/48/64

2001:DB8:FF00::/482001:DB8:FF00:2::/64

2001:DB8:FF00:1::/64

network prefix

RS/RA - /64 prefix on PCDHCPv6 - DNS, domain list

DSLAM

IPv6

CPE

DHCPv6-PD - /48 prefix, DNS, domain list

/48

2001:DB8:FF00::/48

BNG


NDP (RS/RA)

DHCPv6-PD DHCPv6 RelayNDP (RS/RA) + DHCPv6

IPv6 Address Allocation

IPv6 Prefix (CPE)

Delegated IPv6 Prefix

IPv6 CPE BNG DHCPv6


SSR L2/L3 Update in 13B

L2/L3 features on NEPTUNE(IPOS 13B)


› Neptune (2x40G/1x100G) linecard is supporting most of existing SSR features from 11.1up to 13.1, except the following features planned in 13.2:

– NGL2 access facing feature (basically service-instance and the associated features), but the PW transport is supported

– IPv4 PBR– IPv6 ACL and QoS– Port mirroring– MC LAG (what ever phase)– 802.1ag– SSC (traffic steering from Neptune towards an SCC is not supported – i.e. no EPG with

100G)– LAG at 100G

L2/L3 features on NEPTUNE

BFDv6(IPOS 13B)


› The feature is covering single hop BFD IPv6 and single hop single session BFD IPv6 over LAG

› The client processes can be:– Static route– BGP– OSPFv3– IS-IS MT

› No major change compared to IPv4.› Link local IPv6 addresses can be used as neighbor address

BFDV6


BFDv6 Support Matrix

Static Route OSPFv3 BGP+ ISISv6Link-local NOK OK NOK NOT

SUPPORTInterface OK OK OK NOT

SUPPORTGlobal OK NOK OK NOT

SUPPORT1. IPv6 BFD over LAG for static route 的时候， bfd session 中可以使用 global ipv6 地址，也可以使用interface ，而且一端使用 interface ，另一端使用 interface 也是可以建立 bfdv6 session 的 , 但是在SSR 中使用 link local 地址，无法建立 bfdv6 session ， SEOS 可以。

2. IPv6 BFD over LAG for ospfv3 的时候，可以使用 link-local 地址，也可以使用 interface ，但是 bfd session 中不可以使用 global ipv6 地址，因为 ospf3 的 neighbor 是使用 LL 地址建立 neighbor 的。

3. BGP 的 bfd 可以使用 ipv6 global 地址，也可以使用 interface 地址，但是不能使用 LL 地址，因为 bgp neighbor 是使用 global 地址建立的 .

4. 在同时配置 static 和 ospf3 的时候，如果使用的是 interface 的方式建立 bfd session ，那么会看到 2 个session ，一个是 global 地址 for static ，一个是 LL 地址 for ospf3.


› Configuration example:context local interface dual ip address 10.1.1.1/24 ipv6 address 2000::1/64! router bfd interface dual neighbor 3000::4! router bgp <100> neighbor 2000::2 external bfd! ipv6 route 3000::1/64 2001::5 bfd

BFDV6

IS-IS NSR(IPOS 13B)


› NSR is supported for IS-IS including IS-IS MT› NSR is disabled by default and graceful restart helper is enabled by default› Configuration:

router isis 1 [no] nonstop-routing

IS-IS NSR

BGP peer-Group Enhancement

(IPOS 13B)


› Before this feature, peer-group config would only allow commands that ensure a common update for all the neighbors of the peer-group (i.e. next-hop-self not possible in peer-group)

› Now, a peer-group will accept any BGP config and generate the update as needed

BGP peer-group Enhancement


› Concept of neighbor peer-group and address-family peer-group introduces – a neighbor can be part of neighbor peer-group and another address-family peer-group

› The most specific apply in this case.router bgp 2! peer-group test internal description peer_grp_test fast-reset 100 address-family ipv4 unicast route-map rtmap out! peer-group test_af internal address-family ipv4 unicast maximum prefix 344! neighbor 1.1.1.1 internal

peer-group test neighbour peer-group address-family ipv4 unicast

peer-group test_af AF has a more specific peer-group default-originate



[local]ssr(config-bgp-peer-af)#sh bgp nei 1.1.1.1BGP neighbor: 1.1.1.1, remote AS: 2, internal link Version: 4, router identifier: 0.0.0.0 Peer Group member: test State: Idle for 4d02h Description: peer_grp_test Last read 4d02h, last send 4d02h Hold time: configured 180, negotiated 0 Keepalive time: configured 60, negotiated 0 Local restart timer 120 sec, stale route retain timer 180 sec Received restart timer 0 sec, flag 0x0 Minimum time between advertisement runs: 5 secs Source (local) IP address: 0.0.0.0 Received messages: 0 (0 bytes), notifications: 0, in queue: 0 Sent messages: 0 (0 bytes), notifications: 0, out queue: 0 Last active open: 00:00:25, reason: no active or connected route Fast reset timer 100 msecs Address family: ipv4 unicast Peer Group member: test_af BGP table version: 0, neighbor version: 0 Prefix maximum limit: 344 Default-originate configured, default not sent Routes: rcvd 0, imported 0, active 0, history 0, dampend 0, sent 0


attributes inherited from AF peer-group only, route-map out from neighbor peer-group is not applied

attributes inherited from session peer-group


BGP peer-group Enhancement› No peer-group in AF will remove all parameters coming from the AF peer-group

but will block the inheritance from the neighbor peer-group

neighbor 1.1.1.1 internal description nbr_desc peer-group test address-family ipv4 unicast default-originate> no peer-group

show bgp neighbor 1.1.1.1 Address family: ipv4 unicast---- all the params other than configured under neighbor config are set to default.

Default-originate configured, default not sent Routes: rcvd 0, imported 0, active 0, history 0, dampend 0, sent 0


BGP peer-group Enhancement› Using the default command will re-apply the inheritance from neighbor peer-

group even in AF

neighbor 1.1.1.1 internal description nbr_desc peer-group test address-family ipv4 unicast default-originate> default peer-group

show bgp neighbor 1.1.1.1 Address family: ipv4 unicast---- the AF config from neighbor peer-group is applied again

Default-originate configured, default not sent Route map out : rtmap Routes: rcvd 0, imported 0, active 0, history 0, dampend 0, sent 0


BGP peer-group Enhancement› No peer-group command at neighbor level will also remove the AF peer-group.

› In BMT to ensure BGP performance try to get a configuration with a common update:

[local]Redback(config-bgp-peer-af)#sh bgp nei BGP neighbor: 1.1.1.1, remote AS: 0 Version: 4, router identifier: 0.0.0.0 Peer Group member: test State: Idle for 1w3d... Waiting for first session establishment Address family: ipv4 unicast Peer Group member: test Generate Common Updates BGP table version: 0, neighbor version: 0 Routes: rcvd 0, imported 0, active 0, history 0, dampend 0, sent 0 End-of-RIB marker not rcvd Address family: ipv4 vpn BGP table version: 0, neighbor version: 0



› Change in default behavior: by default all the address-family will be off, ipv4 unicast. Before the ipv4 unicast address-family was on by default.

ARP Sync For VRRP(IPOS 13B)


› Inter-Chassis Redundancy (ICR) feature-set enables fast-switchover for VRRP, plus adding support for tracking VRRP instances, etc (future releases)

› 13B Release includes phase 1 of the ICR feature.› In Phase1, better switchover time is achieved by synchronizing ARP cache from

VRRP active to standby› Standby does not have to learn ARP entries when it takes over. This scheme is

useful for MC LAG for IP feature as well to reduce switchover time*

Feature description

* 14A release


› ARP Sync is done over the inter-chassis link between the active and standby VRRP SSRs

› The sync channel, which is UDP/IP based, can be over dedicated directly connected links or over IP network

› Sync control utilizes the infrastructure already available for CPG/ePG redundancy.

› IP/Interfaces configuration expected to be same on both chassis› ARP sync is enabled on the interfaces for which ARP needs to be synchronized.

How it works


example

BSC

RNC

Sync Channel Setup:

1. Configure SSR1[local]SSR1(config)#icr general

[local]SSR1(config-icr)#interface to-peer context icr-context-A port 65001

[local]SSR1(config-icr)#peer 172.68.5.23 port 65001

[local]SSR1(config-icr)#keepalive interval 3 holdtime 10

[local]SSR1(config-icr)#commit

2. Repeat on SSR2 with appropriate peer configuration

3. Verify ICR channel state:[local]SSR1(config-icr)#show icr state

::::::: ICR - State :::::::

State : ACTIVE (WITH PEER) Admin state : Up

Local Node Address : 172.68.5.10 Remote Node Address : 172.68.5.25

SSR1: 172.168.5.10

SSR2: 172.168.5.25

Interface: to-peer, UDP Port 65001, Peer 172.168.5.25/24



Example (contd)

BSC

RNC

ARP Sync for interfaces Setup:1. Configure SSR1

[local]SSR1(config)#context SSR1CTX1

[local]SSR1(config-ctx)#interface BH-SSR1

[local]SSR1(config-if)#ip arp sync icr BH-SSR2 context SSR2CTX1

[local]SSR1(config-if)#commit

2. Configure SSR2

[local]SSR2(config)#context SSR2CTX1

[local]SSR2(config-ctx)#interface BH-SSR2

[local]SSR2(config-if)#ip arp sync icr BH-SSR1 context SSR1CTX1

[local]SSR2(config-if)#commit

3. Verify ARP Sync state:

[SSR1CTX1]SSR1>show arp-cache interface BH-SSR1

------------------------------------------------------------

Display ARP information for interface to-peer:

ARP ICR Sync : On ARP Sync Adj State : ESTAB

Peer Interface : BH-SSR2 Peer Context : SSR2CTX1

SSR1: 172.168.5.10

SSR2: 172.168.5.25



Interface BH-SSR1

Interface BH-SSR2


› The logical connectivity is illustrated in the figure below– The PGW IP (Abis termination point) is an IP address “behind” the NWI-E:s,

hence the VRRP address is used as nexthop to reach the PGW IP

Usecases:Evoc 8100/BSC connectivity

EvoC 8100/BSC1

EvoC 8100/BSC<n>SSR2

SSR1

VRRP/VRRP+BFD

VRRP

VRRP

VRRP/VRRP+BFD

BSC_Abis1

BSC_Abis1

BSC_Abis<n>

BSC_Abis<n>

Legend:

IP interfaceVLAN

PGW IP

PGW IP


USECASES:Evo Controller 8200 / RNC

› The logical connectivity is illustrated in the figure below

EvoC 8200/RNC<n>

EvoC 8200/RNC1

SSR2

SSR1

VRRP/VRRP+BFD

VRRP/VRRP+BFD

Iub_Traffic1

Iub_Traffic1

Iub_Traffic<n>

Iub_Traffic<n>

Iub Host

Iub Host

Legend:

IP interfaceVLAN


Native Transport across microwave in LRAN

NNI

IP/MPLS

MINI-LINKTN

Metro, HRANAccess, LRAN

NNI

IP/MPLS

IP/MPLS

IP/MPLS

Layer 2

(Ethernet)

Cell Sites

4G

3G

2G

UNI

VRRPDefault IP Gw(redundant)

to default IP Gw

21/102 62-11B-009-00

MINI-LINKTN

MINI-LINKTN

MINI-LINKTN

Access, LRAN

Layer 2

(Ethernet)

Cell Sites

4G

3G

2G

UNI

MINI-LINKTN

MINI-LINKTNEthernet

LAG

LAG(optional)

Dual-homed redundant LRAN

Single-homed non-redundant LRAN

USECASES:MBH Transport Network Design


Ethernet – MPL2 interconnect

USECASES:MBH Transport Network Design


MPBN Site

Switch 1

Switch 2

CE 1

IP/MPLS

SSR 2

SSR 1

VPN

VPNSIP

VLAN_1

VLAN_1

Interface IPs (IP1.3 & IP1.4) in VLAN_1 subnet

MP-iBG

P

Re-distribute: static -> MP-iBGPconnected -> MP-iBGP

Re-distribute: static -> MP-iBGPconnected -> MP-iBGP

GE/10GE/LAG

VLAN_1

GE/10GE/LAG

VLAN_1

GE/10GE/LAG

< /30

< /30

FE/GE

Static routes in VPN:To: SIP, NH: CE IP1.4

Static routes in VPN:To: SIP, NH: CE 1 IP1.3

Static routes:To: dest1, NH: SSR VRRP VIP

FE/GE

SSR switch port parameter:- link-dampening up 30000 down 0 restart 600

SSR VRRP parameters:- mode: backup/backup- priority: 254 (SSR 1), 253 (SSR 2)- preempt hold-time: 90- advertise-interval: 300ms or- advertise-interval: 1s + BFD 3x30ms

CE 2

SIP

FE/GE

Static routes:To: dest1, NH: SSR VRRP VIP

Connected routes:To: VLAN_1 subnet (CE 2)

Connected routes:To: VLAN_1 subnet (CE 2)

FE/GE

LAG

GE/10GE

Use CasesMPBN CE connectivity with switch

› L2/L3 CE, indirect, connected/static + VRRP

IP/MPLS

Connected/Static

PE

PEL2

L2

VRRP

CE

VLAN 1


SSR New HW in 14A


SSC2-A Hardware Overview

› Ivy Bridge 95W max› Two additional cores› Increased clock speed, DIMM memory,

storage SSD, and memory frequency› x86-based packet processing capability› Increased storage SSD capacity


SSC2-A DesignFeature SSC1 SSC2-A

CPU/ P-state Sandy Bridge 95WNo P-state power management

Ivy Bridge 95WWith P-state power management

No: of cores 8 10

Clock Speed 2.1GHz 2.4GHz

DIMM Memory 64GB 128GB

Storage SSD 50GB 100GB

Memory freq 1333 MHz 1600 MHz

AMC Integrated AMC slots w/fixed SSD 300GB per AMC

Two hot-swappable, pluggable 400GB AMC slots

Co-processor Cavecreek A0 Cavecreek C1


SSC2-A Additional Features

› Supports Virtual Operating System mode› IPMI shelf controller (IPMC) for AMC support› PCIe HotPlug capability for AMC support› Follows PICMG Specification for AMC.0 and AMC.1› Ivy Bridge brings two additional cores, 25MB of LLC, increased memory

operating frequency, and lower idle power targets› SSC2-A supports a virtualized environment


SSC2-A architecture

DIMM 0

DIMM 1

DIMM 2

DIMM 3

Ivy Bridge CPU0

Ivy Bridge CPU1

AMC0

AMC1

Cavecreek Coprocessor

FPGA

Fabric Access ASIC

DIMM 0

DIMM 1

DIMM 2

DIMM 3

Bac

kpla

ne

Cavecreek Coprocessor

Mux

Mux


› Cold boot: At power-up or when a user runs reload card; normal POD and POST sequences

› OSD boot: By user request with diag out-of-service; more extensive diagnostic tests than a cold boot; OS not loaded

› show chassis with the card is in diag mode: Operational status is oos-diag

SSC2-a Card Initialization


› Provisioning the service card on a router prepares the ASPs on the card to provide card-based services

› A service card can be installed in any line card slot in the chassis

› A service card can be added to the router configuration before it is physically installed in the chassis

› It takes longer for a service card to become active and start processing traffic than a traffic card

SSC2-a Provisioning


› If you configure a slot for an SSC2-A, you can only insert an SSC2-A into the slot for the configuration to take effect.

› If you configure a slot for an SSC2-A, a card mismatch alarm occurs if you insert an SSC1 or SSC1-V2 into the slot.

SSC2-a: Before Configuring


› To provision an SSC2-A in virtualized mode, enter the following command in global configuration mode:

card ssc2-a virtualized slot

SSC2-a Provisioning


[local]Ericsson(config)#card ssc2-a virtualized 8[local]Ericsson(config-card)#

SSC2-a Configuration

Pithos-2AMC

(IPOS 14A)


Mini-Link SP

Multi-Standard RBS

SSR 14A Architecture

AN

SSR

SSR

SSR

Microwave Backhaul

BackhaulRBS and

Small Cell Site

Optical Transport

Switch Site Core

SSR

SSR

SSR

SSRSSR

SSR

SSR

SSR

Switch/Core Routers

Internet and External Networks

WiFi

WiFi

Access, LRAN Metro, HRAN

RNC MSS SACC IMS

BSC SGSN MME

SSR

SPO

ANSSR

SASN

EPG

IP/MPLS

IP Site Infrastructure

SSC2-A

Pithos-2


Pithos-2 AMC Hardware Overview

› Pithos design leveraged for a fully pluggable AMC.0 storage module:– SSC2-A allows the board to be plugged in through new

faceplate– Low-capacity storage AMC module supports

applications running on SSR that require storage– 400 GB of NAND Flash memory on each AMC– IPMI stack on MMC allows SSC2-A to manage Pithos-

2


Pithos-2 AMC architecture

400 GB OF SSDPCIE-SATA

MICRO-CONTROLLER


› The SSC2-A card must either be configured or installed before the AMC modules can be configured

› If the SSC2-A card is installed, but not configured, the SSC2-A card will be auto-configured when the first AMC module is configured

› If the SSC2-A card is neither configured nor installed, the AMC configuration will be denied

Pithos-2: Before Configuring


› To provision or configure the AMC module, use the daughter-card storage slot/port command.

› To display the details of the AMC module, use the show hardware daughter-card slot/<daughter-card-slot> [detail] command.

› To display the administration state of the specified AMC module, use the show daughter-card slot/<daughter-card-slot> [detail] command.

› To reload the AMC module in the slot specified, use the reload daughter-card slot/<daughter-card-slot> command.

› To display the information of the disk on the AMC module, use the show disk daughter-card slot/<daughter-card-slot> command.

Pithos-2 Provisioning


SSR 8000 Series

SSR 8020

› 8 Cards› 4 SW

› 2 ALSW› 2 RPSW

› 4 Cards› 2 ALSW› 2 RPSW

SSR 8010

› 4 Cards› 2 ALSW› 2 RPSW

SSR 8004

SW RPSWALSW

32 GB


› Switch Route Processor with Flash Memory increased from 32G to 64G; this helps us to support existing features while supporting new multi-app features

› Same Power Profile as 32G version

RPSW 64G

[Active Vs Standby] 32GB Vs 32GB




13B *Only 32GB support

Yes (Only 32GB)

Yes (Only 32GB)

Yes (Only 32GB)

Yes (Only 32GB)

14A + (64GB) No Apps and L2/L3 Customers

Yes

Yes

NO*

Yes

14A + With Apps. EPG/VPF/SASN Customers

NO NO

NO

Yes

• Supported only for SWRP 32G to SWRP 64G upgrades. 64G Active, 32G Standby is a non redundant config that is not recommended for

operational deployments


[local]Router-1#Show disk internal detailManufacturer : SMART (/dev/sda)Model : eUSBSerial Number : SPG124600KJ

Manufacturer : SMART (/dev/sdb)Model : eUSBSerial Number : SPG124600L6

Filesystem 1k-blocks Used Available Use% Mounted on/dev/sda1 3872856 3262892 414776 89% /p01rootfs 3880920 3195060 490272 87% //dev/sdb1 15499740 1370792 13347792 9% /var/dev/sda3 7745836 170724 7184736 2% /flash/dev/md0 31047684 5751376 23731588 20% /opt/disk[local]Router-1#

RPSW 64G Configuration


[local]Router-1#show card rpsw1 Slot : Configured Type Installed Type Operational State Admin State-----------------------------------------------------------------------------RPSW1 : n/a rpsw-v2 IS In Service[local]Router-1#

RPSW 64G Configuration


SSR8004 Support in 14A CP01

› SSR8004 是 SSR 的第三种形态，有自己特有的 fantray 和 AC power module 。

› 2xRPSW + 2 ALSW + 6 Fantray + 3 DC

› Available around in AUG 2014


SSR BNG in 14A

CLIPS Dual-Stack(IPOS 14A)


Terminology and Definitions› BBF standard TR-146 defines Subscriber Sessions

BBF Description SSR IPOS

IP Session Generic IPoE subscriber session, dynamically triggered by dataplane or control plane or statically provisioned by OSS layer

• Dynamic CLIPS (DHCP and Non-DHCP)• Static CLIPS• Subscriber VLAN (a.k.a“Bind Subscriber”)

FSOL Subscriber session First Sign Of LifePacket that triggers session creation on the BNG such as : DHCPv4/DHCPv6, Ethernet frame, IPv4 packet, IPv6 RS with Loop Info

• DHCPv4 Discover for DHCP CLIPS• DHCPv6 Solicit for DHCP CLIPS• Any IPv4 packet for Auto-Detect CLIPS

SSR IPOS 14A Concepts FSOL

Dynamic Dual-Stack CLIPS :DHCP-DHCPv6 session

DHCPv4 Discover or DHCPv6 Solicit are FSOL :• First packet (v4 or v6) triggers Dual-Stack session : 1) Bring-Up relevant Stack and 2) Configures the other

stack• 3) Other Stack is brought-up only on reception of relevant FSOL packet (DHCPv4 or DHCPv6)• IPv4 Stack lifecycle managed by DHCPv4 state machine• IPv6 Stack lifecycle managed by DHCPv6 state machine

Dynamic Dual-Stack CLIPS : DHCP-ND session

DHCPv4 Discover is the only FSOL : • Both IPv4 and IPv6 Stacks are brought-up by DHCPv4 Discover• AAA returns IPv4 and IPv6 attributes• IPv4 and IPv6 stacks lifecycles managed together by DHCPv4 state machine

VLAN « Bind Subscriber » session Session FSOL not applicable, VLAN is brought-Up when physical port is Up or for CCOD VLAN when any first packet is received.


SSR 14A Dual-Stack CLIPS scope› FT2508.1 - CLIPS Dual-Stack porting from SEOS12.1.1.2 to IPOS 14A

– Dynamic CLIPS : Support for Routed RG/CPE use case– DHCPv6-PD for Routed RG and SLAAC/ND for CPE WAN numbering– IPv6 CLIPS session (IPv6-Only session) or Dual-Stack CLIPS session with IPv4/IPv6 stacks consolidation into single

session

› FT2508.2 - Additional use cases– Dynamic CLIPS: Bridged RG/CPE use case with CLIPS « DHCP-ND » Dual-Stack session– VLAN “Bind Subscriber” support for SLAAC/ND and DHCPv6-PD

› Note FT2508.2 use cases will be also implemented similarly in SmartEdge SEOS 12.1.1.6


SSR Dual-stack CLIPS scopeROUted RG (FT2508.1) from SEOS12.1.1.2

› Functionally similar to SEOS12.1.1.2 › IPv6 CLIPS (IPv6-only) or Dual-Stack CLIPS session with stack

consolidation› DHCPv6-PD server, RADIUS attributes, PD prefixes (local or RADIUS

driven), ND prefixes (local or RADIUS driven)› Support 1:1 VLAN model or N:1 VLAN model with LDRA (RFC6221)

› Difference with SEOS12.1.1.2› For SLAAC WAN numbering and local ND pools (not from RADIUS), SSR supports persistant ND Prefix in RP Flash

memory› For CLIPS session, in case of node reload same ND prefix is restored from flash memory and reused for CLIPS

session

› Refer to SE12.1 Webinar for additional details


User Device(Dual-Stack)

DHCPv4 Discover

Additional use casesBridged RG/CPE – CLIPS “DHCP-ND” session

Access Request

Bridged CPE

AAA

Access ACCEPT(with v4 and v6 attributes)

DHCPv4 OFFER, REQUEST, ACK

Accounting Alive (DHCPv4)

ND Router Solicitation

Solicited ND Router Advertisement (L2 Unicast, with V6 prefix information, DNS6 **)

Neighbor solicitation (Duplicate Address Detection / GUA address)

Unsolicited ND Router Advertisement (L2 Unicast, with Prefix information, DNS6 **)

DHCPv6 Request (DNS6 option)

DHCPv6 Reply (DNS6 option)

* Only one of the binding attributes is required

**DNS6 option in ND if client supports RFC6106, otherwise client uses DHCPv6 Stateless for getting DNS6 information

• IPv4 Binding attribute* (Framed-IPv4-Address, RB-DHCP-Max-Leases …)

• IPv6 Binding attribute*• Framed-IPv6-Prefix = « 2001::1/64 »

• Framed-IPv6-Pool = « v6-pool »• Additional optional IPv4 or IPv6 attributes

• RB-IPv6-Option, RB-IPv6-DNS

BNG

Accounting start

Optional External DHCPv4 Server (BNG DHCP Proxy)

Additional Optional client transaction• DHCPv6 Stateless for options configurations (e.g DNS6)

• BNG DHCPv6 stateless server

• Dual-Stack CLIPS « DHCP-ND » session*• IPv6 stack brought-up immediately with SLAAC prefix

• Framed-IPv6-Prefix = « 2001::1/64 »• Framed-IPv6-Pool = « v6-pool »

• DHCPv4 Event Accounting enabledIPv4 address assigned by external DHCP server sent to

RADIUS server

IPv4 and IPv6 Stacks Up


Additional use casesBridged RG/CPE – CLIPS “DHCP-ND” session

› Dual-Stack CLIPS “DHCP-ND” session for Dual-Stack Host uses SLAAC for host addressing› IPv6 stack is brought UP immediately together with IPv4 stack› If IPv6 stack has only IPv6 ND prefix configured (No DHCPv6 PD prefix) then IPv6 stack lifecycle (Up/Down events)

follows the IPv4 stack lifecycle› IPv4 stack lifecycle governed by DHCPv4 state machine (Renew, Release, …etc)

› New CLI configuration option “slaac” introduced to enable Dual-Stack CLIPS “DHCP-ND” session at PVC level

port ethernet 3/1!dot1q pvc 100 service clip dual-stack source-mac [slaac] service clips dhcp maximum 32000 context isp1

› “service clips dhcp […]” CLI is required to bring-up CLIPS « DHCP-ND » sessions with DHCPv4 Discover as the session’s FSOL

› DHCPv6 Stateless works without the need for “service clips dhcpv6 […]” CLI› No other CLI config required for CLIPS “DHCP-ND”


User Device / CPE(Dual-Stack)

Access Request

AAA

Access ACCEPT(with v4 and v6 attributes)

DHCPv4 Discover, OFFER, REQUEST, ACK


ND Router Solicitation

Solicited ND Router Advertisement (L2 Unicast, with V6 prefix information, DNS6 **)

Neighbor solicitation (Duplicate Address Detection / GUA address)

Unsolicited ND Router Advertisement (L2 Unicast, with Prefix information, DNS6 **)

DHCPv6 Request (DNS6 option)

DHCPv6 Reply (DNS6 option)

* Only one of the binding attributes is required

**DNS6 option in ND if client supports RFC6106, otherwise client uses DHCPv6 Stateless for getting DNS6 information

• IPv4 Binding attribute* (Framed-IPv4-Address, RB-DHCP-Max-Leases …)

• IPv6 Binding attributes*• Framed-IPv6-Prefix = « 2001::1/64 »• Framed-IPv6-Pool = « v6-pool »• Delegated-IPv6-Prefix = « 2002::1/48 »• Delegated-Max-Prefix =“1”

• Additional optional IPv4 or IPv6 attributes• RB-IPv6-Option, RB-IPv6-DNS …

BNG

Accounting start

Optional External DHCPv4 Server (BNG DHCP Proxy)

Additional Optional client transaction• DHCPv6 Stateless for options configurations (e.g DNS6)• BNG DHCPv6 stateless server

• Dual-Stack « Bind subscriber » session Up*• IPv4 and IPv6 stacks brought-up immediately• If ND prefix configured, ND starts advertising• If DHCPv6-PD received, prefix is delegated

Additional use casesVLAN “Bind Subscriber” session

BNG physical Port/LAGUp event

DHCPv6 Solicit (IA_PD) / Advertise / Request / Reply


DHCPv4 Event Accounting enabled

DHCPv6 Event Accounting enabled


Additional use casesVLAN “Bind Subscriber” session

› No new CLI : IPv6 for “Bind Subscriber” is configured by subscriber record (local or RADIUS)

port ethernet 3/1! dot1q pvc 1 bind subscriber foo@isp1 password bar dot1q pvc 2 through 1000 bind auto-subscriber sub-prefix context1 password pass-prefix dot1q pvc on-demand 1001 through 4095 bind auto-subscriber sub-prefix context1 password pass-prefix

› IPv6 subscriber features supported by subscriber VLAN :› SLAAC : ND, IPv6 /64 prefix, DHCPv6 Stateless server› DHCPv6 Prefix Delegation using on-board DHCPv6 statefull server› IPv6 attributes provisioned through local subscriber record or through RADIUS : subscriber name foo ip address 10.1.1.1 ip source-validation ipv6 framed-prefix 2014:11:2:3::/64 ipv6 delegated-prefix 2002::1/48 ipv6 nd-profile sub-nd ipv6 source-validation


AAA/RADIUS Interface

› No new RADIUS attributes introduced part of this feature› Supported attributes are similar to SE12.1.1.2 CLIPS

› Enhancement for local ND pool assignment› In SEOS12.1.1.2 local ND pool can be configured through Framed-IPv6-Pool attribute› In 14A, RADIUS attribute value Framed-IPv6-Prefix = « ::/64 » can be used as a hint

› « ::64 » is a new value supported in IPOS 14A › System will allocate any ND prefix from any available pool

› No changes with Event Accounting for IPv6 stack and DHCPv6 supported for « DHCP-DHCPv6 » CLIPS, « DHCP-ND » CLIPS, « Bind Subscriber » sessions


Enhanced ND prefix handlingND Prefix persistEnce

› Problem statement: when using ND prefix assigned from local pool, CLIPS session’s ND prefix can be re-allocated on session restart or IPv6 stack restart

› When using ND prefix assigned from RADIUS, same prefix can be re-assigned after session restart from RADIUS

› After system reload or port flap, CLIPS session is re-authenticated

› Solution: new process « AAAHelperd » introduced› Similar function as DHCP-Helperd and DHCPv6-Helperd› Manages assigned ND prefixes, storage in NV memory and restore ND prefixes used by CLIPS sessions

› Application: Routed RG and Bridged RG with local ND pool› Routed RG use case : when ND is used for WAN numbering, on node restart/port flap or IPv6 stack

restart, same ND prefix can be restored› Bridged RG use case : on node restart/port flap, CLIPS “DHCP-ND” session will restore the same IPv6

prefix for the host


Enhanced ND prefix handlingND Prefix persistEnce

› On CLIPS session down (node reload/port flap event) or IPv6 stack down event, ND prefix is marked and reserved

› ND prefix is reserved in NV memory for a duration (aging-time default=15min)› if CLIPS session or IPv6 stack is not restored after expiration of aging duration (15min default),

ND prefix is released back to free ND pool › Aging-time can be changed through a hidden CLI global command :

[local]SSR(config)#aaa ipv6-prefix-recovery aging-timer ?

0..100 Time in mins after which the prefix should be released. 0 will clear all backup prefixes


DHCP/CLIPS ConfigurationsIPOS 14A CLI configuration examples FSOL AAA Attributes

returnedBehaviour

service clips dual-stack DHCPv4 N/A *NOT* a valid config, no clips session will be created.

DHCPv6 N/A *NOT* a valid config, no clips session will be created.

service clips dhcpDHCPv4

IPv4IPv6Dual-Stack

• IPv4-Only CLIPS session• NO CLIPS session• IPv4-Only CLIPS session, IPv6 attributes ignored *

DHCPv6 N/A NO CLIPS session

service clips dhcpv6 source-mac DHCPv4 N/A NO CLIPS session

DHCPv6IPv4IPv6Dual-Stack

• NO CLIPS session • IPv6-Only CLIPS session• IPv6-Only CLIPS session, IPv4 attributes ignored *

service clips dhcpservice clips dhcpv6 source-mac DHCPv4

IPv4IPv6Dual-Stack

• IPv4-Only CLIPS session• NO CLIPS session• IPv4-Only CLIPS session, IPv6 attributes ignored *

DHCPv6IPv4IPv6Dual-Stack

• NO CLIPS session• IPv6-Only CLIPS session• IPv6-Only CLIPS session, IPv4 attributes ignored *

service clips dual-stack source-macservice clips dhcpservice clips dhcpv6 source-mac

DHCPv4 IPv4IPv6Dual-Stack

• IP4-Only CLIPS session• NO CLIPS session• Dual-Stack CLIPS session : IPv4 Stack Up, IPv6 Stack Configured **


• NO CLIPS session• IPv6-only CLIPS session• Dual-Stack CLIPS session : IPv4 Stack Configured **, IPv6 Stack Up

Notes :* Attributes is displayed in show command as “Not applied”

** IPv4 or IPv6 stack configured (attributes configured) and waiting for DHCPv4 or DHCPv6 packet to bring the stack Up


DHCP/CLIPS ConfigurationSIPOS 14A CLI configuration examples FSOL AAA Attributes

returnedBehaviour

service clips dual-stack source-mac slaacservice clips dhcp


• IP4-only CLIPS session• NO CLIPS session• Dual-Stack CLIPS session : IPv4 Stack Up, IPv6 Stack Up ***


• NO CLIPS session• NO CLIPS session• NO CLIPS session

service clips dual-stack source-mac slaacservice clips dhcpv6 source-mac


• NO CLIPS session• NO CLIPS session• NO CLIPS session


• NO CLIPS session• IPv6-only CLIPS session• IPv6-only CLIPS session, IPv4 attributes ignored *

service clips dual-stack source-mac slaacservice clips dhcpservice clips dhcpv6 source-mac


• IP4-only CLIPS session• NO CLIPS session• Dual-Stack CLIPS session : IPv4 Stack Up, IPv6 Stack Up ***


• NO CLIPS session• IPv6-only CLIPS session• Dual-Stack CLIPS session : IPv4 Stack Configured, IPv6 Stack Up ***

Notes :* Attributes is displayed in show command as “Not applied”

** IPv4 or IPv6 stack configured waiting for DHCPv4 or DHCPv6 packet to bring the stack up*** IPv6 stack is brought up automatically because of the « slaac » configuration keyword


Scaling / Performance

› Dual-Stack CLIPS subscriber bring-up rate: 275 subs/sec– RADIUS Authentication and accounting– Dual Stack subscribers with QoS and ACLs

Note : parent VLAN PVC counts for an additional circuit in the system’s capacity

System Level Line card Level

Single Stack CLIPS Subscribers

768K 96K

Dual Stack CLIPS subscribers

576K 48K


Limitations› *NOT* In Scope of SSR 14A :

› IPv6 support for Auto-Detect CLIPS (a.k.a Non-DHCP CLIPS)› IPv6 support for Static CLIPS› DHCPv6 Statefull Address assignment (IA_NA)

› CLIPS and Bridged GW use case : › IPv6 only client not supported since CLIPS “DHCP-ND” session requires DHCPv4 FSOL› IPv6 only client will be supported in future release (SSR 14B) with DHCPv6 statefull address assignment and SSR as

DHCPv6 relay

› CLIPS and « Bind Subscriber » under same VLAN/PVCSimultaneous IPv6 CLIPS and IPv6 « Bind Subscriber » operation under same same VLAN/PVC is not supported, only one of the following combinations is supported :

› Dual-Stack/IPv6 “Bind subscriber” and IPv4 CLIPS (IPv4-Only sessions)› IPv4-Only “Bind subscriber” and Dual-Stack/IPv6 CLIPS sessions

› Hitfull ICR using VRRP is not supported for IPv6 CLIPS

› No Support for DHCPv6 Relay Agent (RFC3315) in front of SSR– a.k.a L3 connected IPv6 CLIPS› IPv6 client has to be L2 connected to SSR or through an LDRA (RFC6221)

LNS Dual-Stack(IPOS 14A)


CORE

L2TP LAC & LNS

BNG (LAC)

PPPoE Subscribers

L2TP Tunnel

L2TP Tunnel

L2TP Tunnel

ISP1

ISP2

ISP3

BNG (LNS)

AGGREGATION

RADIUSRADIUS

RADIUS

RADIUS

Accounting (Start/I

nterim/Stop)

Access-Request/Response

AN

AN

AN

SSR 13B SSR 14A


CORE

Protocol Layers

Carrier SSR BNG (LAC)

PPPoE Subscribers

L2TP Tunnel

ISP1

BNG (LNS)

AN

AN

AN

AGGREGATION

RADIUS

Layer 2Layer 3

DataIP

PPPPPPoE

DataIP

PPPL2TPUDP

IP

DataIP


PPPoE [PADI/PADO/PADR/PADS]

LCP

AuthSCCRQ

SCCRP

SCCCN

ICRQ

ICRP

ICCN

IPCP

IPv6CP

ND & DHCPv6

Data & PPP session keepalive

L2TP tunnel keepalives

RADIUS RADIUS

Access Request

Session Setup

Access Accept

Access Request

Access Accept

Tunnel Setup: If no tunnel established before

LAC LNS

L2TP Call Flow

Subscriber

Access Core

54 1312

1

2

6

7

8

9

10

11

14

3

15

16

17

20

Auth success

18

LCP (optional based on LNS configuration)

19


› L2TP requires identifiers (local names) on both sides

› L2TP is established from Client to Server and never from Server to Client

› L2TP parameters are applied once and stick until the tunnel is disconnected (transaction oriented)

› There is a server option (LNS) to allow unnamed tunnels to be accepted (assumes the network is trusted)

L2TP local names

local-name(Client Authen ID)

&tunnel-auth key

(Tunnel password)

local-name(Server Authen ID)

&tunnel-auth key

(Tunnel password)

Request

Confirmation

L2TP LAC L2TP LNS

The LNS validates credentials as provided by

the LAC


1) LAC sends local-name and tunnel-auth key to LNS via SCCRQ

1) Local-name / tunnel-auth key

Summary of L2TP local name and peer name

LAC LNS

2) LNS validates credentials LAC and confirms thumbs-up via SCCRP

2) Confirmation

3) Tunnel is established and assigned tunnel id

4) Within the LAC tunnel, multiple domain aliases can be configured;PPP sessions from multiple domains can use same tunnel

4) Domain abc Domain xyz

abc

xyz


› Subscriber sessions can be single-stack or dual-stack– Single-stack subscriber sessions have only one type of IP service configured and exclusively support one

type of traffic (IPv4 or IPv6)

– Dual-stack subscriber sessions are authorized for both IPv4 and IPv6, and can simultaneously support both IPv4 and IPv6 traffic

› LAC and LNS single-stack (IPV4 or IPV6) and dual-stack (IPv4 and IPv6) traffic:– Supported on IPv4 L2TP tunnels only

– Not supported on IPv6 L2TP tunnels

› When PPP sessions are terminated on an Ericsson LNS:– IPv6 packets are not fragmented on the LNS

– IPv6 packet is encapsulated in the IPv4 tunnel, and IPv4 tunnel packets are fragmented

Dual-Stack LNS


LNS: Link Aggregation Group

› L2TP tunnels supported over LAGs› PPA3-LP line cards:

– U-LAG (packet hashed)– Link-pinning LAG (circuit hashed)

› VLANs can also be in load-balance mode (packet hashed)– Eco-LAG for connectivity not supported

› NP4 line cards supported over U-LAG (packet hashed)

BNG (LAC)

L2TP Tunnel ISP1

BNG (LNS)

AN AGGREGATION

RADIUS

LAG


Subscriber Features and Services

Example of supported subscriber features:

› Metering/Policing

› PWFQ (with multi-slot/LAG/ECMP restrictions)

› PWFQ overhead profile

› Source address validation

› ACL

Example of subscriber features not supported:

› PWFQ in multi-slot config or with LNS slot redundancy

› Multicast

› Volume limit with LNS slot redundancy

› IPv6 (ND, DHCPv6 prefix delegation)

› Absolute/Idle timeout

› RSE on LNS slot1 only

› QoS propagation

Press PAUSE on your video player at any point in this lesson or download the PowerPoint file to review any commands in detail.


LNS Hardware Support

LAC-Facing

Card

BNG LC

or

L2/L3 LC

LNS Subscriber

Card

BNG LC only

Trunk Card

BNG LC

or

L2/L3 LC

BNG (LAC)

L2TP Tunnel Internet

SSR - LNS


LNS Session Homing

› LNS card selection algorithms:– Route: Default method - selects a card that has a route towards LAC– Priority: Selects a card based on the configured card preference

› If L2L3 (NP4) cards are used as LAC-facing cards:– Must configure the selection algorithm to be priority based with

‘lns card selection priority’– BNG (PPA3-LP) cards must be configured as LNS cards with

‘lns card <slot_no> preference <priority>’


L2TP Slot Redundancy

X

LNS

LAC

Carrier IP Network

IP PPP L2TPIP

IP PPP


Scaling / Performance

› LNS subscriber bring-up rate : 275 subs/sec– RADIUS Authentication and accounting– Dual Stack subscribers with QoS and ACLs

System Level Line card Level

Single Stack LNS Subscribers

768K 96K

Dual Stack LNS subscribers

576K 48K

L2TP tunnels 64K No limit at a Line-card level


Connectivity towards LAC

› L2TP tunnels are supported over – ECMP– LAG

› For BNG(PPA3LP) cards: It is supported over - U-LAG(packet hashed) - Link-pinning LAG (Circuit Hashed): VLANs can also be in load-balance mode (i.e.

Packet Hashed)- Economical LAG for connectivity is NOT supported.

› For L2L3(NP4) cards: It is supported over U-LAG (packet-hashing)

› L2TP tunnels between LAC and LNS can be in L3VPNs


Limitations› All subscriber features supported on LNS subscribers except for the following

limitations:– Rflow not supported– Circuit mirroring not supported (Though LI is supported)– RSE for LNS subscribers is only supported on slot 1– Only Queuing policy supported for LNS subscribers is PWFQ with following limitations:

› Connectivity towards LAC and the subscribers home slot should be the same› The connectivity towards LAC should not be over LAG› Slot redundancy is not supported, as it can create issues when a port goes down


How to Configure LAC and LNS

Configure the ports / circuits facing the subscriber PPPoE sessions (just like PTA)

Create a new context called LAC and implement L2TP LAC configuration

Create a new context called LNS and implement L2TP LNS configuration

Configure a context ISP1 and implement regular PTA configuration (multibind interface, pool, authentication, etc.)

Monitor the behavior5

4

3

2

1


2

1

How to Configure LAC and LNS

Configure the ports / circuits facing the subscriber PPPoE sessions (just like PTA)

Create a new context called LAC and implement L2TP LAC configuration

Create a new context called LNS and implement L2TP LNS configuration

Configure a context ISP1 and implement regular PTA configuration (multibind interface, pool, authentication, etc.)

Monitor the behavior5

4

3


Binding *2: The binding for the L2TP session is based on a session oriented binding, L2TP level command:

session-auth {pap | chap | chap pap} [context ctx-name | service-policy svc-policy-name]

Waiting room

Waiting room

LNS Tunnel setup

Client auth IDAuth-key

Ctx tunnelBinding *1

Ctx xyzDomain isp-1

user@isp-1

Binding *2

Binding *1: This example assumes IP connectivity from LAC to context tunnel (LNS) to the network (that would be the

first binding required)

L2TP negotiation

room

PPP negotiation room

Signaling

LAC

PPP Session (user@isp-1)

L2TP


Specific challenges for LNS

The LNS terminates the LAC tunnel and receives all the subscriber sessions that the LAC sends it

The LNS determines which context should authenticate the PPP session:1. Define domains within context (most straightforward)

2. Force the subscriber session to destination context› Session authentication chap pap context isp1

3. Combine aaa last-resort with global authentication to decide on destination context


Specific challenges for LNS

› Be aware that the session authentication statement is applied to ALL sessions arriving on that tunnel

› Typically one would not terminate the PPP session in the same context where the LNS tunnel is terminated

– Security considerations– Logical separation improves operational model


ETH 3/10

LNS Configuration (facing LAC)

LNS

context LNS

1

interface LNS-backboneip address 1.1.1.2/24

2

port ETH 3/10no shut

bind int LNS-backbone LNS

4

l2tp-peer name LAC-side media udp-ip remote ip 1.1.1.1 local 1.1.1.2function LNS-only

tunnel-auth key 12345session-auth chap paplocal-name LNS-side

3

READY


LNS

LAC

IP Transit

LNScontext LNS

interface LNS-backboneip address 1.1.1.2/24

l2tp-peer name LAC-side media udp-ip remote ip 1.1.1.1 local 1.1.1.2function LNS-only tunnel-auth key 12345session-auth chap pap

port ETH 3/10no shutbind int LNS-backbone LNS

Context LNS will receive the LAC tunnels

IP connectivity for the tunnel

LNS Configuration (facing LAC)

ISP


Subscriber Termination Context

ISP1

context ISP1domain isp1.net

1

interface pool-1 multibindip address 100.1.1.1/24

ip pool 100.1.1.0/24

2

subscriber name user password user

4

subscriber default ip address pool

3

READY


LNS

LAC

IP Transit

PPP Subscriber

context ISP1

domain isp1.net

interface pool-1 multibindip address 100.1.1.1/24ip pool 100.1.1.0/24

subscriber default ip address pool

subscriber name user password user

Regular subscriber termination configuration

Match on subscriber’s username suffix

Subscriber Termination Context

ISP


Dual-Stack LNS Configuration

[local]Ericsson(config)#context lns[local]Ericsson(config-ctx)#domain isp[local]Ericsson(config)#interface core[local]Ericsson(config-if)#ip address 210.1.1.1/24[local]Ericsson(config-if)#ipv6 address 1000:0:0:1::1/64[local]Ericsson(config-if)#exit[local]Ericsson(config)#interface lns-eth1[local]Ericsson(config-if)#ip address 200.1.1.2/24[local]Ericsson(config-ctx)#interface pool multibind[local]Ericsson(config-if)#ip address 10.1.0.1/16[local]Ericsson(config-if)#ipv6 address 3000:0:1::/48[local]Ericsson(config-if)#ip pool 10.1.0.0/16[local]Ericsson(config-if)#ipv6 pool 3000:0:1:1::/64 3000:0:1:8::/64



[local]Ericsson(config-ctx)#nd profile test[local]Ericsson(config-nd-profile)#ra-interval 5[local]Ericsson(config-nd-profile)#exit[local]Ericsson(config-ctx)#subscriber default[local]Ericsson(config-sub)#ipv6 nd-profile test[local]Ericsson(config-ctx)#subscriber name joe1[local]Ericsson(config-sub)#password test[local]Ericsson(config-sub)#ip address pool

[local]Ericsson(config-sub)#ipv6 framed-pool pool[local]Ericsson(config-sub)#exit[local]Ericsson(config-ctx)#subscriber name joe2[local]Ericsson(config-sub)#password test[local]Ericsson(config-sub)#ip address pool



[local]Ericsson(config-ctx)#l2tp-peer name lac media udp-ip remote ip 200.1.1.1 local 200.1.1.2[local]Ericsson(config-l2tp)#tunnel-auth key rbak[local]Ericsson(config-l2tp)#function lns-only[local]Ericsson(config-l2tp)#local-name lns[local]Ericsson(config)#card ge-10-port 6[local]Ericsson(config-card)#exit[local]Ericsson(config)#port ethernet 6/6[local]Ericsson(config-port)#no shutdown[local]Ericsson(config-port)#bind interface core lns[local]Ericsson(config-port)#exit[local]Ericsson(config)#card ge-10-port 9[local]Ericsson(config-card)#exit[local]Ericsson(config)#port ethernet 9/1[local]Ericsson(config-port)#no shutdown


Dual-stack LNS show commands

‘show l2tp peer <peer name> tunnel <tunnel id> session <session id>’‘show l2tp group’‘show l2tp summary’ ‘show l2tp global ipc’ ‘show subscriber summary all’ ‘show subscriber active all’

Dynamic Non-DHCP CLIPS

(IPOS 14A)


Non-DHCP CLIPS: What It Is

› Non-DHCP CLIPS: A way to create dynamic CLIPS circuit based on traffic sourced from an IP address

› Independent of DHCP protocol

› The new circuit behaves exactly as a CLIPS circuit except that the creation and deletion of circuit is independent of DHCP protocol

› Circuit tear-down based on session-timeout or idle-timeout


Non-DHCP CLIPS: Uses

› Use case:

– Used for out-of-band subscriber management, when SSR BNG is not in the path of the DHCP messaging between subscriber and DHCP server

› Alternate use case:

– CG NAT not supported on static (non-subscriber) circuits such as interfaces


Non-DHCP CLIPS: How It Works

Create a service-policy to configure IP ranges that trigger this feature:

service-policy name <policy-name>[no] allow clips ip range <start-address> <end-address>

– Up to 4 ranges in the service-policy– IP addresses are implicitly excluded from CLIPS circuit creation if they don't fall into the pre-

configured ranges under service-policy– No mechanism for explicit exclusion


Non-DHCP CLIPS: How It Works

Apply the service-policy to a parent circuit:

port ethernet <slot/port> [no] service clips auto-detect [direct] [maximum <max-num>] context <ctx-name> service-policy <policy-name>

– Command enables the feature on PPA to detect the packets that fall within the allowed range and then look into the demux table

– Parent circuit is either connected to L2 gateway or L3 gateway, but not both at the same time


Non-DHCP CLIPS: Operation

› Source IP address of the packet is used as “Username” in RADIUS access-request for authentication

› Supported on PPA2 and PPA3 Ethernet cards

› Existing line card limits on circuit scale apply

› Supports IPv4 only; IPv6 not planned currently

› Make sure there is a firewall sitting between the end users and the SSR BNG


Non-DHCP CLIPS: Limitations

› Not supported over CCOD

› Not supported with “encaps multi”

› Cannot coexist with other CLIPS types under a parent circuit

› Using session-timeout to terminate non-DHCP CLIPS sessions may not work correctly in some cases


service-policy name policy0 allow clips ip range 15.1.1.2 15.1.1.20 !service-policy name policy1 allow clips ip range 17.1.1.2 17.1.1.20

context ctx1!interface i1 ip address 16.1.1.1/24

interface i2 multibind ip address 15.1.1.1/24 ip pool 15.1.1.0/24 interface i3 multibind ip address 17.1.1.1/16 ip pool 17.1.0.0/16

aaa authentication subscriber none!subscriber default ip address pool...

Non-DHCP CLIPS Configuration


Non-DHCP CLIPS CLI enhancements for O&M

To display a subscriber triggered by this feature:

[ctx1]ericsson#show clips auto-detect

circuit ipaddr username------------------------------------ --------------- -----------

9/1 vlan-id 2:1 clips 131073 15.1.1.2 15.1.1.2

...



To display the rules in a service-policy and the number of parent circuits using the service-policy:

[local]ericsson#show clips service-policy policy name : policy reference count : 1 address range 15.1.1.2 15.1.1.20

where reference count is the number of parent circuits using this policy.



The following commands are enhanced for this feature:

show clips summaryshow clips countersshow clips counters detail


SSR L2/L3 UPdate in 14A

RSVP MBB(IPOS 14A)


RSVP MBB• With this feature SSR supports Make Before Break (MBB) for RSVP on all NP4 based LCs:

• MBB is supported on RSVP-TE LSP and primary LSP

• RSVP-TE signals the LSP with Shared Explicit style to avoid double booking of the bandwidth on common links for both old and new LSPs

• Traffic from the old LSP is switched to the new LSP only after the new LSP is established successfully and is done without any traffic loss

• All attributes configured on old LSP remain and are taken into consideration on the new LSP

• Old LSP is torn down once the traffic is switched to the new LSP


RSVP MBB• If the old LSP goes down before the MBB procedure is finished, MBB is aborted and the old

LSP is put to down state and the new LSP is removed. If the new LSP goes down during MBB, traffic is moved back to the old one and the new LSP is removed. In either case, traffic loss might be observed

• Both ISIS and OSPF are supported as IGP protocols

• Existing MPLS OAM, L3VPN, L2VPN, IPoMPLS, LDPoRSVP, GREoMPLS services on old LSP are also supported on the new LSP

• Use cases: Global reversion and LSP Re-optimzation

• For both use cases, MBB is initiated from the ingress node of the LSP


RSVP MBB• Global Reversion: When a LSP is protected by a bypass LSP, the link/node failure will cause

FRR to switch the traffic to the bypass LSP. The point of local repair sends FRR in use notification to the ingress node of the LSP. This notification triggers the ingress node to query the CSPF for the route and signals a new LSP if the route query is successful. If the new LSP is setup successfully, the traffic is moved to the new LSP and the old LSP is deleted.

• Head-end of primary LSP uses PATH_ERR to compute CSPF while excluding the failed link except when a backup path is pre-configured.

• Alternatively, when failure occurs on the link of the ingress or on link towards neighbor node and there is bypass protecting the ingress node can use interface down event as trigger for the global reversion.

• Global reversion applies to primary LSP. It is enabled as default when FRR is enabled on the LSP.


RSVP MBB• Route Re-optimization: When route re-optimization is configured, the make before break

procedures can be triggered when the re-optimization timer is expired. Each active primary LSP is checked by CSPF to see if there is better path available. If one is available, a new LSP is signaled. After the new LSP is established successfully, the traffic is moved to the new LSP and the old LSP is deleted.

• Re-computation is done only for LSPs which are link/node protected

• Non-CSPF LSP (the LSP with source-path) is excluded from global reversion using MBB while CSPF LSP defined with explicit-route (via dynamic-path) is eligible for global reversion

• The tie-break factor in CSPF is: largest available bandwidth, fewest hop counts and random pick if the first two checks end up as a tie. Please refer to the CSPF feature specification for more information.


RSVP MBB• KPI:

• Up to 10K LSPs can be supported for RSVP MBB

• In a small network (5 nodes) SSR can re-compute, signal and switch traffic within 5 seconds of receiving PATH_ERR for a LSP assuming re-computation and signalling is successful the first time and there is no hold time configured. Currently hold time is not configurable and the time is set to 10 second as default

• SSR supports global reversion and re-optimization for up to 16 LSPs for the same egress endpoint


RSVP MBB• Limitations:

• MBB support requires an acknowledgement from old LSP when the traffic finishes moving to new LSP. If a negative acknowledgement or no acknowledgement is received, the traffic moves back to old LSP and packet loss might be observed during this time

• MBB is not supported for backup and bypass LSP

• LSP counters are not maintained after MBB

• SSR supports global reversion and re-optimization for up to 16 LSPs for the same egress endpoint


RSVP MBB• Configuration:

The following command can be used to enable and disable route re-optimization and specify the time interval to periodically perform route re-optimization on the router rsvp level. context local router rsvp [no] reoptimization [interval <value>] The command enables the functionality of route re-optimization and set the timer interval to be the value specified in <interval> in minutes. The range of the interval is 60-527040. The default is 1440 minutes. The no form of the command or no configuration indicates there is no route re-optimization.


RSVP MBB• <Show Command 1> show rsvp lsp

This LSP summary show command is enhanced to indicate which LSP is a new (mbb) LSP. It is marked as <mbb> appended to the LSP name in the LSP field. The name of the LSP remains the same. Please note this is going to be the case only during the period of time when the make-before-break procedure is taking place. Before and after the mbb, the LSP is displayed as normal without mbb mark. [local]Bean#show rsvp lspLSP TID Ingress Endpoint State FRR O Prtctlsp_a_b 6 22.31.22.31 80.80.80.80 Up E NoneLsp7 7 77.77.77.1 100.100.100.1Up T NoneTest 1 80.80.80.80 35.35.35.35 UP I Nonetest <mbb> 1 80.80.80.80 35.35.35.35 UP I None


RSVP MBB• <Show Command 2> show rsvp lsp <lsp-name>This show LSP command displays the details the LSP specified by the lsp-name. If both old LSP and new mbb LSP exist when mbb is performing and when this show command is issued, then the details of the both LSP will be displayed as it is shown in the following example. Before and after the mbb, only one LSP is displayed as normal. [local]Bean#sh rsvp lsp test --- RSVP LSP test (Tunnel ID: 1) --- Ingress : 80.80.80.80 Endpoint : 190.190.190.190Origin : Ingress LSP State : UPExtended Tunnel ID : 80.80.80.80 LSP ID : 2Traffic-Eng : default State Transitions : 0Downstream Nhop : 15.1.1.1 Downstream Intf : 15.1.1.2Downstream Intf Name: to-tb1Downstream Nbr : 15.1.1.1 Downstream Label : 1600Setup Priority : 7 Holding Priority : 0Last Downstream Tx : 4 Last Downstream Rx : 2Next Timer in (sec) : 12 Lifetime (sec) : 157Time to Die (sec) : 155 B/W (Bytes/sec) : 0LSP cct : 255/3:1023:63/0/1/3IGP Shortcut : DisabledSession Attr : Local-Protect Node-Protect May-Reroute Record-LabelUse CSPF Route : Yes Record Route : YesDynamic Route : Recorded Route (hops: 1): 190.190.190.190/32 Label flags 1, value 1600CSPF Route (hops: 1): 15.1.1.2/32


FAST VRRP over LAGSSR now supports Fast VRRP over ULAG on NP4 based LCs:

• The feature-set remains the same as fast VRRP over a single link

• Configuration is the same as non-LAG Fast VRRP

• In the case of link failure, the LAG infrastructure picks the available constituent link and sends VRRP traffic

• Active home slot/PFE and backup home slot/PFE are selected for each VRRP session

• Active and backup home slots/PFE are load balanced across line cards. The load balancing is based on VR ID + circuit id


FAST VRRP over LAG• KPI:

• The minimum VRRP advertisement interval must be 50 milliseconds

• In case of slot failure, VRRP traffic is sent over the backup slot in less than 50 milliseconds

• In case of link failure, VRRP traffic is sent over the next available constituent link in less than 50 milliseconds

• Traffic failover is within 200ms when the VRRP interval is 50ms

• VRRP session failure detection is 150 milliseconds (50 * 3). This is the minimum duration that the SSR supports


FAST VRRP over LAG• The maximum supported VRRP session per NP4 PFE is 4K

• Hitchhiker and Neptune support 2K VRRP sessions with min of 50 ms Rx/Tx timers and 4K sessions with min of 100 ms Rx/Tx timers

• Vogon supports 4K VRRP sessions with min of 50 ms Rx/Tx timers and 8K sessions with min of 100 ms Rx/Tx timers


IPSec scale and performance improvements• SSC-1 supports up to 8K IPSec tunnels, up from 50 tunnels in 13A

• IPSec throughput on SSC-1 is 13.5 Gbps (UL + DL) up from 1 Gbps in 13A

• A SSR 8020 filled with 18 SSC-1 cards can support up to 150K IPSec tunnels and 240G throughput

• Bytes Gbps (AES-128 + SHA1)

64 1.5

650 9

800 10

1024 11

1400 13.5

• IPSec Webinar link :http://etube.paib.internal.ericsson.com/video/IP-Sec-Gateway-on-Smart-Services-Card/68697cb5af04a1751434b206b6bb71e0

IPFRR LFA OSPF & LDP (IPOS 14A)


Why IPFRR?› Switch-over times that are comparable to those of Sonet/SDH,

RSVP-TE FRR and carrier-grade Ethernet– Target: <50ms fail-over

› Example measurement results for fail-over time:– OSPF with Hello based failure detection: >2 seconds– OSPF with L2 upcall or BFD: 150-300ms– IPFRR: 20-30ms

outage with OSPF

outage with IPFRR

Example:


› Protocols (OSPF, ISIS, BGP, LDP) compute back-up next-hop

› RIB and LM provides new next-hop infrastructure

› FABL and ALD provides new infrastructure and switchover mechanism

› FFN and ETI provides event propagation.

› BFD and ETI publishers provides detection mechanisms

OSPF IS-IS BGP LDP

RIB LM

FABL-FIB FABL-MPLS

ALD

NPU

ETI/FFN

IPFRR LFA – OSPF AND LDPINTERNAL ATCHITECTURE


IPFRR LFA – OSPF AND LDP

Link Protecting Node protecting Down stream

N

S E D

2

11

1

1

N

Loop Free: D_opt(N, D) < D_opt(N, S) + D_opt(S, D)

Node Protecting: D_opt(N, D) < D_opt(N, E) + D_opt(E, D)

Downstream: D_opt(N, D) < D_opt(S, D)


IPFRR LFA – OSPF AND LDPSRLG’s

S E D

N3

SRLG 1

N2

N1

SRLG 2

Shared Infrastructure


IPFRR LFA – OSPF AND LDPLDP LFA RFC 5286‘Follow-the-lead’

› OSPF provides the ‘lead’ primary and backup

› LDP follows if/when labels are available

› LDP LSR must distribute labels to all neighbors

› Liberal label retention mode› Downstream unsolicited mode

S E D

2

11

1

1

NLDP Label binding

LDP Label binding


› IP Fast Reroute LFA OSPF Interface Configuration

› [no] lfa

Default – prefer ECMP, try node protecting lfa, if none – try link protecting

› Constrains:– lfa exclude ecmp – look for a lfa outside of ECMP

bundle– lfa protect

› link-only - Only link protecting neighbors will be chosen as LFAs

› node-only - Only node protecting neighbors will be chosen as LFAs

›

lfa scheduling› The OSPF router submode command syntax is:›

› [no] lfa scheduling 0..1000 20..4000› Primary SPF limit for inline LFA computation (in

milli-seconds) › Limit on LFA SPF single pass computation (in milli-

seconds) SRLGs.

›

›

IPFRR LFA – OSPF AND LDPConfiguration OSPF


› IP Fast Reroute LFA Backup OSPF Interface Configuration

›

› The router ospf interface submode command syntax is:

›

› [no | default] lfa backup›

› Where backup refers to Next Hops on the backup interface that can be used as LFAs. If no lfa backup is configured, LFAs may still be computed for next hops whose primary path is using this interface if lfa is configured. The default is that the interface is eligible to be an LFA backup

›

›

› For the Shared Risk Link Group (SRLG) OSPF Interface Configuration

›

› The router ospf interface submode command syntax is:

›

› [no] srlg <srlg-number> ›

› Where the <srlg-number> is an SRLG number in the range of 0 to 4,294,967,295. This is compatible with the Generic Multiprotocol Label Switching (GMPLS) definition of SRLGs.

›

›

IPFRR LFA – OSPF AND LDPConfiguration OSPF


› IP Fast Reroute LFA router ldp configuration:

› [no] ipfrr

› Default – on, if ldp is configured and ospf calculates a lfa, ldp would create labeled entry. Could be disabled, mostly for debugging purposes.

IPFRR LFA – OSPF AND LDPConfiguration ldp


Limitations1. Support is limited to SSR. There will be no support for SE.

2. Support is limited to OSPFv2 support for unicast IPv4 routes.

3. Support will be mutually exclusive with IGP shortcuts or LDP-over- RSVP tunneling mode. This will be enforced by configuration.

4. Routes using IPsec tunnels will not included in this phase.

5. Support for LFA in the backbone area and virtual links is mutually exclusive. This will be enforced by configuration. Checking for a full mesh of virtually connected ABRs in each transit area, as described in section 2.0 of RFC 5286, could be added in a future phase.

6. Micro-loop prevention is out for scope for this phase.

7. Since the primary SPF computation and route download is given priority over the LFA computation, LFAs for routes unchanged during a primary computation may remain in the RIB/FIB during periods of frequent OSPF topology changes.


Targets/tested› IP LFA computation MUST support for up to 64 IGP interfaces and at least 10,000 IGP routes

› LDP shall support at least 1000 LSPs with a backup labels

› RIB shall support at least 2000 double barrel next-hops ›

›

Neptune Feature Gaps(IPOS 14A)


› Neptune (2x40G/1x100G) linecard is supporting most of existing SSR features from 11.1 up to 14A. With the limited engineering resources available on NP4, we decide to limit the use of Neptune to core facing features:

– NGL2 access facing features are not supported (basically service-instance and the associated features), but the PW transport is supported

– MC LAG is not supported

› From 14A, EPG is supporting Neptune linecards:– Traffic steering to SSC is supported on Neptune– The support for EPG on Neptune – VRRP is supported on Neptune– LAG 100G is supported

NEPTUNE FEATURE GAPS

IPv6 URPF(IPOS 14A)


› IPv6 uRPF was supported on PPA3LP from SSR13B.› This feature is adding IPv6 uRPF support for NP4 linecards.› It’s supporting strict and loose mode:context ctx interface itf ipv6 address 10:10::1/32 ipv6 verify unicast source reachable-via {any | rx} [allow-default] [acl <acl-name>]

› New counters:[local]Ericsson# show circuit counters details…RPF CountersRPF Drops : 0 RPF Drops : 0RPF Suppressed : 0 RPF Suppressed : 0RPF v6 Drops : 0 RPF v6 Drops : 0RPF v6 Suppr. : 0 RPF v6 Suppr. : 0

…

IPV6 URPF

MC-LAG Phase 2a(IPOS 14A)


› This phase is adding the following on top for MC-LAG introduced in SSR13A:– ARP synchronization over the interchassis link– RIB synchronization over the interchassis link– Sub-second link/port failure detection through the use of 802.1ag CCM messages.

MC LAG PHASE2A


MC LAG PHASE2A


MC LAG PHASE2A! GENERAL ICR CONFIGicr general interface icr-loopback context test port 61555 peer 100.1.1.11 port 61555 keepalive interval 7 holdtime 21!context test!!INTERFACES NEEDED FOR ICR COMMUNICATIONinterface icr ip address 100.1.1.1/30! interface icr-loopback loopback icr transport ip address 100.1.1.10/32!!EXAMPLE OF AN INTERFACE WITH ARP-SYNC CONFIGURED (BOUND TO MC-LAG) interface lag1 ip address 20.1.1.1/24 ip arp sync icr!!ROUTING INTRODUCED TO ENABLE INTER-CHASSIS COMMUNICATIONrouter bfd neighbor 100.1.1.2

minimum transmit-interval 100 minimum receive-interval 100! router ospf 1 area 0.0.0.0 interface icr interface icr-loopback passive! ip route 40.1.1.0/24 100.1.1.2!DOUBLE-BARREL ROUTE FOR IP FRR; TRIGGERED ON LINK-GROUP PUBLISHER ip route 50.1.1.0/24 20.1.1.2 100.1.1.2 bfd track link data-plane ip route 100.1.1.11/32 100.1.1.2!! ** End Context **!!SYSTEM-WIDE TRACK CONFIGURATION FOR LGD TO TRACK BFD STATE CHANGESmulti-chassis link-group track bfd1 action renegotiate-link log


MC LAG PHASE2Alink-group mclag1 encapsulation dot1q mac-address 00:00:de:ad:00:11 maximum-links 2 minimum-links 2 lacp active lacp admin-key 32767 lacp system-id priority 20 mac-address 00:00:de:ad:00:11 multi-chassis revertive hold-time 10 !TRACK CONFIGURATION FOR LGD TO TRIGGER ON CFM EVENTS track CFM action compute-min-link log dot1q pvc 10 bind interface lag1 test!link-group lg1 encapsulation dot1q dot1q pvc 10 bind interface icr test!!! tracked object configuration!CFM PUBLISHER WITH CCM-FAIL OPTION SPECIFIED (USED BY LGD TO DETECT CONST FAIL)tracked-object CFM cfm instance 1 domain-name dom

maintenance-association ma remote-mep 2 ccm-fail log!BFD PUBLISHER (USED BY LGD TO DETECT INTER-CHASSIS LINK FAILURE)tracked-object bfd1 bfd neighbor 100.1.1.2 context test!LGD PUBLISHER (USED BY IPFRR TO CHANGE BARRELS)tracked-object link link-group mclag1 log!! MC-LAG PORTSport ethernet 1/9 no shutdown link-group mclag1 lacp priority 200!port ethernet 1/10 no shutdown link-group mclag1 lacp priority 200!


MC LAG PHASE2A! Interchassis link portsport ethernet 4/5 no shutdown link-group lg1!port ethernet 4/6 no shutdown link-group lg1!!CFM CONFIGURATION ON MULTI-CHASSIS LINK-GROUP CONSTITUENT LINKS!Ethernet connectivity fault management configuration!oam instance 1 cfm level 0 domain-name dom maintenance-association ma ccm std-interval 3ms no port-status-tlv no interface-status-tlv mep 1 lg mclag1 direction down per-constituent remote-mep 2

LDP NSR(IPOS 14A)


› In addition to NSR supported for OSPF starting for SSR13A, IS-IS supported from SSR13B, LDP NSR is supported starting from SSR14A.

› NSR is disabled by default and graceful restart helper is enabled by default› Configuration:

router ldp [no] nonstop-routing

LDP NSR

VRF RT Import-MAP(IPOS 14A)


› We now can use route-map for the imported the route-target in the BGP configuration.

› This feature is coming with a slight CLI change for the import and export statement:

context <foo> vpn-rd <x> router bgp vpn address-family [ipv4 unicast|ipv6 unicast] [no] export [no] [route-target A:B | route-map <foo> ] [no] import [no] [route-target A:B | route-map <foo> ]

VRF RT IMPORT-MAP


› Example:context vpn1 vpn-rd 1:1 router bgp vpn address-family ipv4 unicast export route-map foo1 route-target 1:1 route-target 1:2 route-target 1:3 import route-map foo2 route-target 1:1 route-target 1:2 route-target 1:3

VRF RT IMPORT-MAP

Bridge on NP4(IPOS 14A)


SSR 6

SSR 5

TYPES OF MAC LEARNING

SSR 1

AN

ANSSR 2

SSR 3

SSR 12

SSR 11

SSR 9

‹ Qualified Learning‹ Unqualified Learning‹ Static Learning ‹ Dynamic Learning

SSR 4SSR PE

SSR PE

SSR 10

SSR 8

SSR 7

SSR PE

SSR PE


MAC ADDRESS LEARNING COMPARISONS

Unqualified Learning

Qualified Learning

Static Learning

‹ MAC Aging is disabled for BFEs of static MAC addresses‹ There is a maximum of 1000 MAC addresses configurable

under a bridge and on a bridge circuit.‹ A maximum of 16K Static MAC addresses can be configured

on the system

Dynamic Learning

‹ MAC Aging is enabled for BFEs of dynamic MAC addresses‹ Dynamic MAC learning can be disabled and enabled on a

bridge dynamically‹ Dynamic MAC Addresses are not learned on a circuit that is

part of a bridge on which MAC Address learning is disabled

VS


(Green) PW in full Mesh (point to multi point)

Shared Bridge / Transparent Bridge / 802.1d Bridge / Unqualified Bridge

PW within an LSP (Pink)

SSR PE 3

SSR PE 2SSR PE 1

Purple CEPurple CE

Green CE

Green CE

Green CE

Other CE

Other CE

Targeted LDP signalling between PE SSRs to exchange VC labels for pseudowires.

Independent VLAN Bridge / 802.1q Bridge / Qualified Bridge

SSR

SSR

SSR

SSR

SSR

SSR

SSR

SSR

SSR

SSR

Bridge Instance (AKA Virtual Switch Instance / VPLS service instance)

‹ Flooding/Unicast Forwarding‹ MAC Address learning / MAC Address Aging‹ Loop Prevention – VPLS uses ‘Split Horizon’ concept to prevent loops

SSR

A bridge instance bound with a mesh of VPLS pseudowires set across PE & CE SSRs in the same virtual LAN

Attachment Circuit (AC)

An SSR bridge INSTANCE with VPLS PSEUDOWIRES

LSP Tunnel over MPLS

AC

AC


DESTINATION MAC ADDRESS LOOKUPS

IVLIndependent VLAN Learning

SVLShared VLAN Learning

Bridge ID + VLAN ID

Independent VLAN Bridge / 802.1q Bridge / Qualified Bridge

Bridge ID Shared Bridge / Transparent

Bridge / 802.1d Bridge / Unqualified Bridge

‹ SSR Release 14A uses both IVL and SVL

‹ Both IVL & SVL use a single VPLS Service Instance / Bridge Instance BFE (Bridging Forwarding Engine) Table

SSR 1 PE

SSR 4

AN

AN

SSR 3

SSR 6

SSR 2

SSR 5

VLAN Bridge Domain LAG1

KEY

KEY

Destination MAC (DMAC)

Learned SMAC


PACKET FLOODING ON TO SERVICE INSTANCES

› Tiered Flooded-Packet Replication

Ingress/Egress Line card

Egress Line card

Egress Line card

FABRIC

Incoming broadcast

packet

PFE FAP

PFE

PFE

FAP

FAP

PFE

PFE

FAP

FAP


PACKET FLOODING ON TOPSEUDOWIRES

IngressLine card

Egress Line card

Egress Line card

FABRIC

Incoming broadcast

packet

PFE FAP

PFE

PFE

FAP

FAP

PFE

PFE

FAP

FAP

Flooding of the packet on the Ingress PFE on to Pseudowires after Replication of the Frame


Bridging & packet forwarding entries

SSR PE

SSR 4

AN

AN

SSR 3

SSR 6

SSR 2

SSR 5

VLAN Bridge Domain LAG1

‹ Distribution of BFE entries between PFEs‹ Synchronization of BFE entries between PFEs and RPs

SSR

Bridge Forwarding Entry (BFE) Table

Bridge Name

VLAN MACAddress

Adjacency/Out-Circuit

Purple 100 MAC A 10/2 (SI-1)

Purple 100 MAC B 200


SPLIT HORIZON GROUPS

SSR SHG Configuration Replaces Smart Edge Trunk/Tributary CLI

SHG 1 and 2

Bridge1

1

2

3

4

5

6

SHG 1

SHG 2

SHG 2

No SHG (= trunk)SHG 1

Source Circuit

Destination Circuits

1 Circuit 6 only

2 or 3 Circuits 4, 5 and 6

4 or 5 Circuits 2, 3 and 6

6 All circuits

‹ All VPLS HUB PW Circuits in a bridge are part of animplicit Split Horizon group

‹ A Circuit can belong to a maximum of 2 Split Horizon groups


Bridging ATTRIBUTESConfigurable Directly Under the Bridge or Bridge Profile

Bridging Attribute Purpose Bridge Bridge Profile

MAC Aging Checks for Idle BFEs

MAC Move DropMAC Move Limit

Manages Re-Learning on a Different Circuit

Filter/Drop MACs Filters MAC Moves > 5

MAC Loop Detection Detects loops within bridge networks or bridge profile circuit

Qualified LearningEnable and Disable

Enables or disables Qualified Learning

Dynamic MAC Learn Disables Dynamic MAC Learning

SHG (Split Horizon Group) Defines flood domain for circuits bound to a bridge domain

MAC Learn Limit Sets # of MAC addresses that can be learned on bridge circuit.

Restricted MAC Learn Restricts dynamic MAC Learning on a bridge circuit

Broadcast / Multicast /Unicast Rate Limit

Rate limit configurations for broadcast / Multicast / Unicast packets


Bridging LIMITS‹ Bridging for SSR Release14A is supported on both port-based / LAG-based NGL2 circuits.

‹ SSR does not support Spanning Tree (but can transport the BPDU); Shortest Path Bridging is planned for the next release.

‹ MC-LAG is not supported over Bridging/VPLS access circuits.

‹ L2ACL are planned for the next release, as is BVI support.

‹ Bridging on the SSR is available on three NP4-based line cards.‒ GE-40-port | 10GE-10-port | 40-100GE-2-port

‹ The current limitation on the NP4 PFE circuit table is 24,000 entries.

‹ The KPI requirement for VPLS bridging is based on the 24K circuit table limitation.

Note: When VPLS PW is provisioned in 24K circuits, some of the circuit is used for MPLS LSP/IP for VPLS routing.


Bridge scaling

SSR

MAC per PFE 1M

MACs per system 20M

MAC learning rate 1M /s

Bridge instances 12,000

Access Circuit per bridge 1,000

Bridge access circuits per line card

40x1GE 24,000

10x10GE 48,000

SSR


Configuration EXAMPLE


Bridge1



1/38 1/39

port ethernet 1/39 no shutdown

encapsulation dot1q service-instance 1

match dot1q 1000

bridge bridge1 port 1/38 service-instance 1 port 1/39 service-instance 1

‹ STEP 1: Set up the service-instances 1/38 and 1/39

‹ STEP 2: Create the bridge and associate the

service-instances


Bridging SPLIT HORIZONGROUPS CONFIGURATION

Bridge1

1/38 SI1

1/38 SI2

1/38 SI4

SHG 1 and 2

SHG 1

SHG 1

bridge bridge1 port ethernet 1/38 service-instance 1 split-horizon-group shg1 shg2 port ethernet 1/38 service-instance 2 split-horizon-group shg1 port ethernet 1/38 service-instance 4 split-horizon-group shg2


OTHER Bridging supports

SSR 14A Release also supports configuration for:

‹ Static/Dynamic MAC tables

‹ MAC Aging

‹ MAC Learn Limit

‹ Broadcast/Multicast/Unknown Rate-limit

‹ MAC Move Detection

VPLS on NP4(IPOS 14A)


VPLS› Service-instance access circuit (VLAN manipulation, VLAN ranges)› Distributed learning› Qualified learning› Split Horizon Group even on PW (Hub PW will be part of an implicit SHG for

loop prevention, so will be limited to one additional SHG)› LDP signaling› Flat VPLS› H-VPLS› PW redundancy› PW mapping to LSP


VPLS Configuration Overview


Configure VPLS in four steps:

Create the PW peer profileCreate VPLS PW InstanceCreate a new VPLS service instanceBind the VPLS PW with the bridge instance(Qualified or Unqualified)

SSR

SSR SSR

SSR

VPLS

1

2

3

4


pseudowire peer-profile PE1 peer 1.1.1.1 vc-type vlan

pseudowire instance 1 pw-id 100 peer-profile PE1


bridge bridge1 port ethernet 1/15 service-instance 1 vpls pseudowire vlan 10 pseudowire instance 1

Configuration Overview

Create a new pseudowire peer profile

Create a new pseudowire instance or range of instances

Create a new service instance or range of instances

Create the bridge, associate the service-instance and the pseudo-wire



VPLS SCALING

SSR

SSR SSR

SSR

VPLS

SSR

MAC per linecard 1M

MAC per system 20M

VPLS instances 12,000

VPLS PW per bridge 2K

VPLS PW per system 24K


VPLS access circuits per linecard

40x1GE 24,000

10x10GE 48,000


L2 OAM SCALING

SSR

SSR SSR

SSR

VPLS

SSR

Scaling per linecard

802.1ag/Y.1731 3.3msec timer 200

802.1ag/Y.1731 10msec timer 1,000

802.1ag/Y.1731 100msec timer 4,000

802.1ag/Y.1731 1sec timer 8,000

Scaling per system

802.1ag/Y.1731 3.3msec timer 4,000

802.1ag/Y.1731 10msec timer 12,000

802.1ag/Y.1731 100msec timer 64,000

802.1ag/Y.1731 1sec timer 128,000


VPLS

› Limit to keep in mind:› SSR does not support BGP-signaled VPLS, nor BGP auto-discovery for LDP VPLS, the way

forward is EVPN.


SSR&SE configuration differences


access link-groupIF SE LG CONFIGURATION IS ENTERED:

link-group LAG_4/6-11/6 access

% Invalid input at '^' marker

EXPECTED CONFIG ON SSR:link-group LAG_4/1-11/1 link-pinning

encapsulation dot1qdot1q tunnel ethertype 88a8no load-balanceqos pwfq scheduling physical-portmac-address 02:01:01:0d:04:01dot1q pvc 2614 profile T2_ULL encapsulation 1qtunnel description T2_IDBRE_07592_'SESTO S. GIOVANNI'_SVLAN_2614dot1q pvc 2614:2531 profile T2_ULL

link-pinning option need to be used when subscribers are configured on link-group and card type is 1-10ge-20-4-port.


qos policiesFollowing commands have been modified with a new optional keyword, card-family, to support the new functionality:

qos congestion-avoidance-map qos policy metering qos policy policing qos policy pwfq qos profile overhead

In each of these commands, the card-family keyword can be set to 2, which represents PPA3LP-based cards. If the card-family keyword is not set, card family 1, which is NPU4-based is used as default.card-family 1• 40-port GE• 10-port 10GE• 1-port 100GE or 2-port 40GEThis is the default setting when no card family is specified.card-family 2• 4-port 10GE (PPA3LP)• 20-port GE and 2-port 10GE (PPA3LP)


qos policiesIF A POLICY IS CONFIGURED WITH A CARD-FAMILY BUT IT IS APPLIED TO A DIFFERENT FAMILY CARD:

dot1q pvc 2614:2531 profile T2_ULL description TELE2_VOIP_ACCESS_MIEDA039 bind interface TELE2_VOIP_ACCESS_MIEDA039 TELE2_VOIP_ACCESS qos policy metering TELE2_VOIP_ACCESS

% cannot bind policy because card-family is incompatible

POLICIES CONFIGURATION EXAMPLES:qos policy METER1 metering!qos policy METER2 metering card-family 1!qos policy METER3 metering card-family 2!qos policy PWFQ1 pwfq!qos policy PWFQ2 pwfq card-family 1!qos policy PWFQ3 pwfq card-family 2


bulkstats policyIF SE BULKSTATS CONFIGURATION IS ENTERED:

bulkstats policy "SVLAN-ULL"localdir /mdtransfer-interval 5sample-interval 5 remotefile format "%s_SVLAN-ULL_%s" hostname contextreceiver 10.178.6.134 primary mechanism sftp login bngcsv encrypted

58CE1B24768EFACA


EXPECTED CONFIG ON SSR:bulkstats policy "SVLAN-ULL"

localdir /mdtransfer-interval 5sample-interval 5 remotefile format "%s_SVLAN-ULL_%s" hostname contextreceiver 10.178.6.134 primary mechanism ftp login bngcsv encrypted

58CE1B24768EFACAOnly ftp protol is supported towards receiver.


nat poolIF SE NAT POOL CONFIGURATION IS ENTERED:

ip nat pool CGN-pool-FOA napt paired-mode logging paired-mode subscriber over-subscription 128 port-limit 2048 logging-profile CGN-logging context DSL_DATA address 2.39.0.1 to 2.39.0.60 port-block 1 to 4


EXPECTED CONFIG ON SSR:ip nat pool CGN-pool-FOA napt paired-mode logging paired-mode subscriber over-subscription 128 port-limit 2048 logging-profile CGN-logging context DSL_DATA address 2.39.0.1 to 2.39.0.60 exclude <port-start to> to <port-end>

Ports in a nat pool need to be excluded by configuring a specific range


nat policyIF SE NAT POLICY CONFIGURATION IS ENTERED:

nat policy CGN-default-FOA enhanced


EXPECTED CONFIG ON SSR:nat policy CGN-default-FOA! Default class ignore inbound-refresh udp icmp-notification! Named classes access-group CGN-ACL class CGN pool CGN-pool-FOA DSL_DATA endpoint-independent filtering udp inbound-refresh udp icmp-notificationEnhanced option not available. P2MP nat obtained when «endpoint-indipendent filtering <udp|tcp>» is configured.


gre tunnelIF SE LOGGING CONFIGURATION IS ENTERED: tunnel gre LI-IP_Milano_1

peer-end-point local 10.177.18.14 remote 10.169.200.6 context DSL_LIbind interface LI-IP_Milano_1 DSL_LIforward output LI-IP_Milano_1


EXPECTED CONFIG ON SSR: tunnel gre LI-IP_Milano_1peer-end-point local 10.177.18.14 remote 10.169.200.6 context DSL_LIbind interface LI-IP_Milano_1 DSL_LI

The binding associate the tunnel circuit interface to the tunnel.


gre tunnelIF SE LOGGING CONFIGURATION IS ENTERED: tunnel gre LI-IP_Milano_1

peer-end-point local 10.177.18.14 remote 10.169.200.6 context DSL_LIbind interface LI-IP_Milano_1 DSL_LIforward output LI-IP_Milano_1


EXPECTED CONFIG ON SSR: tunnel gre LI-IP_Milano_1peer-end-point local 10.177.18.14 remote 10.169.200.6 context DSL_LIbind interface LI-IP_Milano_1 DSL_LI

The binding associate the tunnel circuit interface to the tunnel.


gre tunnelIF SE LOGGING CONFIGURATION IS ENTERED:

qos profile OVH overheadencaps-access-line ether-aal5-llc


EXPECTED CONFIG ON SSR:qos profile OVH overheadencaps-access-line value <0..255>

The number of bytes of encapsulation overhead need to be specified.


loggingIF SE LOGGING CONFIGURATION IS ENTERED:

logging tdm console


EXPECTED CONFIG ON SSR:no configuration needed

Logging of vxworks events do not need to be logged any more.


SSR Troubleshooting


Agenda

ssr Basic System hardware Checks

SSR System Processes

SSR RPSW

SSR Line cards

SSR basic Command Line Interface Commands

ssr Fan Tray and Power Modules

SSR Log Files

SSR Debugging

SSR Connectivity

SSR basic CLI CommandsSSR Troubleshooting


[local] Ericsson#

TTY START TIME REMOTE HOST ADMINISTRATOR

--------------------------------------------------------------------------------

pts/1 Wed May 30 23:24:14 2012 155.53.154.223:tel noc@local

pts/2 Wed May 30 23:27:12 2012 155.53.235.128:tel engineer@local

* pts/3 Thu May 31 00:10:43 2012 155.53.234.189:tel admin@local

Getting started

show administrators active

This Session


Show history commandshow clock[local] Ericsson#

Thu May 31 00:44:55 2012 IST

[local] Ericsson#

[local] Ericsson(config)#


[local] Ericsson#

sh clock

configure

[local] Ericsson#


system description MY SSR

end

[local] Ericsson#

system description MY SSR

end

show history

end

show history show history configuration

configure

end

show history

show history conf

system description This is My SSR

show history

!configure

USER EXEC MODE


Show history Global

[local] Ericsson#

Jun 26 23:15:01 show chassis

Jun 26 23:15:18 show port



Jun 26 23:17:01 show clock

Jun 26 23:17:01 conf

Jun 26 23:17:08 system description This is my SSR

Jun 26 23:17:11 sh hist

Jun 26 23:17:14 commit

Jun 26 23:17:17 sh hist

Jun 26 23:17:34 exit

Jun 26 23:17:36 sh hist

show history global

Time allows pinpointing command that may have triggered an event

show history global

Show History = Current Admin Session only


Searching in the cli with emacs[local]Ericsson# Building configuration...

Current configuration:!! Configuration last changed by user '%RCM%' at Thu Feb 8 07:57:05 2011!service multiple-contexts

--- cut ---

interface 1 ip address 10.1.1.105/24

administrator redback encrypted 1 $1$........$4qhlVuh2HDOCu/EbYfbM6.---(more)---

24 rows

/abc This will search for a match on the characters “abc”

n Repeat the previous search in forward direction

N Repeat the previous search in reverse direction

g

G

Top of output

Bottom (end) of output

b Move up one page

Space bar Move down one page

show configuration


Searching in the cli with grep

[local]Ericsson# show config | grep <pattern>

› Filtering output based on word match.

› Examples:[local]Ericsson# show config | grep contextno service multiple-contextscontext local

[local]Ericsson# show log | grep failNov 14 11:02:24: %TUNNEL-3-ERR: ISM Client reg failed. Unknown tunnel type 5Nov 14 11:02:24: %TUNNEL-3-ERR: ISM Client reg failed. Unknown tunnel type 6Nov 14 11:02:35: %CSM-6-SYS: ALARM_MINOR: Chassis power failure - side B


Aliasesshow port counter 1/14 live

[local]Ericsson#

Port Type

1/14 ethernet

packets sent : 3290057 bytes sent : 2589414193

packets recvd : 3133985 bytes recvd : 2466478663

send packet rate : 0.00 send bit rate : 0.00

recv packet rate : 7914.52 recv bit rate : 49834963.14

rate refresh interval : 60 seconds

[local] Ericsson#recv packet rate : 7914.52 recv bit rate : 49834963.14

[local]Ericsson#

Enter configuration commands, one per line, 'end' to exit

[local]Ericsson(config)#


[local]Ericsson#

[0] (P14RCV)# sh port counter 1/14 live | grep 'recv bit'


sh port counter 1/14 live | grep 'recv bit'

configure

alias exec P14Receive sh port counter 1/14 live | grep 'recv bit'

end

P14Receive

Commands can grow quite LONG!

Repeated Numerous times

Aliases: Use Short command in place of Pre Defined Longer command


Macros[local]Ericsson(config)#

[local]Ericsson(config-macro)#



[local]Ericsson#

[10] (P14TIME)# sh clock

Wed Jun 27 00:32:57 2012 IST

[20] (P14TIME)# show port counters 1/14 live

Port Type

1/14 ethernet






P14TIME Multiple Commands executed with one command

Useful to Space out Sequence numbers for future insertion of commands.

macro exec P14TIME

seq 10 show clock

seq 20 show port counters 1/14 liveend

Basic System hardware Checks

SSR Troubleshooting


System Hardware Health

Are there any hardware Problems?


System Hardware Checks

[local]Ericsson#

Timestamp Source Severity Description

--------------------------------------------------------------------------------

May 30 17:33:06.509 PM1 Minor Input Failure - Feed B




May 30 17:33:09.875 PM5 Minor Power Module Missing




show system alarm

Power Module Alarms

Minor

Major

Critical


Major System alarm


[local]Ericsson(config-port)#

[local]Ericsson(config-port)#

[local]Ericsson#


--------------------------------------------------------------------------------

Jun 13 00:19:50.940 1/19 Major Link down

port ethernet 1/19

no shutdown

end

show system alarm

Port with no cable connected

System Alarms easily created


Critical System alarm[local]Ericsson(config)#

[local]Ericsson(config-card)#

[local] Ericsson#


--------------------------------------------------------------------------------Jun 13 00:23:45.080 17 Critical Card Missing

card ge-40-port 17

end

show system alarm

No Card Present in Slot 17

[local]SR1-1(config)#card ge-40-port 17

[local]SR1-1(config-card)#deactivate

[local]SR1-1(config-card)#end

[local]SR1-1#sh sys alarm


--------------------------------------------------------------------------------


System Hardware LED

Minor alarm

Critical alarm


System Hardware Checks[local] Ericsson#

Slot Type Serial No Rev Mfg Date Payload

----- -------------------- -------------- ------- ----------- -------

N/A backplane CF90000CM9 R2G 29-MAY-2012 N/A

FT1 ft CE510004C7 R2C 26-NOV-2011 N/A

FT2 ft CE510004C9 R2C 26-NOV-2011 N/A

PM1 pm BR81556727 R2A 13-JUL-2011 N/A

.

PM8 pm BR81556750 R2A 13-JUL-2011 N/A

RPSW1 rpsw CF90000AZC R2H 06-DEC-2011 OK

RPSW2 rpsw CF90000A61 R2F 31-OCT-2011 OK

ALSW1 alsw CF90000B3C R2N 08-DEC-2011 OK

ALSW2 alsw CF90000B4U R2N 08-DEC-2011 OK

SW1 sw CF90000BN9 R2M 12-DEC-2011 OK

SW2 sw CF90000BMR R2M 12-DEC-2011 OK

SW3 sw CF90000BKW R2M 14-DEC-2011 OK

SW4 sw CF90000BMA R2M 14-DEC-2011 OK

1 ge-40-port CF90000BGX R2H 27-DEC-2011 OK

12 ge-40-port CF90000BYT R2H 02-JAN-2012 Power D

show hardware

(Not all output is displayed)

Card 12 Powered Down

[local]SR1-1# sh conf card 12

Building configuration...

Current configuration:

!

end


More detailed hardware info

[local] Ericsson#

backplane Display backplane hardware information

card Display hardware information for a specific card

detail Display detail hardware information for all cards

fantray Display fantray hardware information

power-module Display power-module hardware information

thermal Display hardware thermal information for all cards

| Output Modifiers

show hardware ?


Line Card hardware information[local] Ericsson#

Slot : 1 Type : ge-40-port

Serial No : CF90000BGX Hardware Rev : R2H

Mfg Date : 27-DEC-2011

Activated Time : 0 min

WSFP-W011 : 3

WLCC-W011 : 7

Voltage 12.000V : 11.965 (-0%) Voltage 1.000V : 1.005 (+0%)

Voltage 1.500V : 1.490 (-1%) Voltage 1.000V : 0.998 (-0%)





Inlet Temp : Normal (32 C) Card Temp Status : Normal

Payload Status : OK OSD Status : Not Run

POD Status : Passed

Failed LED : Off IS LED : On

Standby LED : Off Swap LED : Off

Ejector Switch : 1 (Locked)

Last Payld Reset : Power On

Active Alarms : NONE

show hardware card 1 detail

Expected Value Actual Value


RPSW hardware information[local] Ericsson#

Slot : RPSW1 Type : rpsw

Serial No : CF90000AZC Hardware Rev : R2H

Mfg Date : 06-DEC-2011

Activated Time : 22 h

Phalanx : 3.0.13

Spanky : 02.02

Voltage 54.000V : 54.032 (+0%) Voltage 12.000V : 12.031 (+0%)






Payload Status : OK OSD Status : Passed

POD Status : Passed

Failed LED : Off IS LED : On

Standby LED : Off Swap LED : Off

Ejector Switch : 1 (Locked)

Last Payld Reset : Admin


sh hardware card rpsw1 detail


ALSW hardware information[local] Ericsson#

Slot : ALSW1 Type : alswSerial No : CF900009WK Hardware Rev : R2HMfg Date : 07-OCT-2011Activated Time : 6 hFarquaad : 09Shiba : 03.06Voltage 54.000V : 53.287 (-1%) Voltage 12.000V : 12.000 (+0%)Voltage 3.300V : 3.299 (-0%)Inlet Temp : Normal (24 C) Card Temp Status : NormalPayload Status : OK OSD Status : Not RunPOD Status : PassedFailed LED : Off IS LED : OnStandby LED : Off Swap LED : OffEjector Switch : 1 (Locked)Last Payld Reset : Reset ButtonActive Alarms : NONE

Power LED : OnFan LED : OffCritical Alarm LED : OnMajor Alarm LED : OffMinor Alarm LED : On

sh hardware card alsw1 detail

Minor alarm

Critical alarm


Hardware System alarms[local] Ericsson#

Slot : N/A Type : backplane

Active Alarms : N/A

Slot : FT1 Type : ft




Slot : PM1 Type : pm

Active Alarms : Input Failure - Feed B








Active Alarms : Input Failure - Both Feeds


Active Alarms : Input Failure - Both Feeds

--More--

sh hardware detail | grep option -E 'Alarm|Slot'

(Not all output is displayed)

SSR System ProcessesSSR Troubleshooting


SSR Software Architecture – Modular Operating System

› Each process runs in protected memory space

– Failure of one protocol does not affect other protocols

› Whole System Reload not required when an individual process fails

CPU

Line Card LP

RPSW

OSPF

RIBd

FIB

PPPd App#1d App#2d

ALd

PPP QoS

QoSd

App#1 App#2

PM

FABL

ALD

RP OS

PI

PD


non-critical Process Failure Scenario

Line

CardLine

Card

CLI, SNMP, other

ConfigProcess

Database

OSPF

Routing Information Base

MulticastBGP Static

OS Kernel

Process Manager

PPP

CLI, SNMP, other

ConfigProcess

Database

OSPF


MulticastBGP Static

OS Kernel

Process Manager

PPP

Active ALSW

Active RPSW

Standby RPSW

Line

CardLine

Card

CLI, SNMP, other

ConfigProcess

Database

OSPF


MulticastBGP Static

OS Kernel

Process Manager

PPP

CLI, SNMP, other

ConfigProcess

Database

OSPF


MulticastBGP Static

OS Kernel

Process Manager

PPP

Active RPSW

Standby RPSW

OSPF died OSPF restart

1) Problem Occurs in Software

• Only individual process is effected

• All other processes continue to run

All established connections remain up and forward traffic

2) Process is restarted

• Only effected process is restarted

• Done completely automatically


Line

Card Line

Card

CLI, SNMP, other

ConfigProcess

Database

OSPF


MulticastBGP Static

OS Kernel

Process Manager

PPP

CLI, SNMP, other

ConfigProcess

Database

OSPF


MulticastBGP Static

OS Kernel

Process Manager

PPP

Active ALSW

Active RPSW

Standby RPSW

3) Process comes back up

• Process starts running again

• NO RPSW switch over has to occur

All established connections remain up and forwarding traffic


SSR System Processes Verification

[local] Ericsson# show process

Load Average : 0.06 0.01 0.00

NAME PID SPAWN MEMORY TIME %CPU STATE UP/DOWNns 3245 1 5576K 00:00:35.30 0.02% run 17:17:39u2l 3265 1 3864K 00:00:01.24 0.00% run 17:17:39metad 3266 1 30696K 00:00:02.86 0.00% run 17:17:39evtmd 3287 1 4320K 00:00:03.77 0.00% run 17:17:36pnsd 3291 1 4672K 00:00:02.06 0.00% run 17:17:35cmsp_rpswd 3292 1 4348K 00:01:11.77 0.02% run 17:17:35cms_server 3298 1 5336K 00:00:10.74 0.01% run 17:17:35cmsp_ceqa 3300 1 4592K 00:00:13.14 0.00% run 17:17:35cmsp_alsw0 3301 1 4472K 00:00:03.54 0.00% run 17:17:35cmsp_alsw1 3302 1 4468K 00:00:03.54 0.00% run 17:17:35cmsp_sw0 3303 1 4464K 00:00:03.14 0.00% run 17:17:35cmsp_sw1 3304 1 4468K 00:00:03.15 0.01% run 17:17:35cmsp_sw2 3305 1 4468K 00:00:03.14 0.00% run 17:17:35cmsp_sw3 3306 1 4468K 00:00:03.17 0.00% run 17:17:35cmsp_cmbhub 3325 1 5900K 00:03:11.72 0.04% run 17:17:35pad 3330 1 23260K 00:01:41.56 0.02% run 17:17:35--More--

5 sec 1 min 5 min averages • Run

• Stop

• Demand

2

Indicates Process has restarted


SSR System Process using CPU

[local] Ericsson# show process | grep option -E '..\.[1-9][1-9]%'

ns 3245 1 5576K 00:00:36.27 0.01% run 17:47:37cmsp_rpswd 3292 1 4348K 00:01:13.84 0.02% run 17:47:33cmsp_cmbhub 3325 1 5900K 00:03:17.25 0.04% run 17:47:33pad 3330 1 23260K 00:01:44.29 0.02% run 17:47:33com 3982 1 24740K 00:00:14.34 0.01% run 17:47:01ospf 4043 1 5528K 00:01:13.99 0.01% run 17:47:00sysmon 3642 1 5288K 00:00:42.20 0.01% run 17:47:02vrrp 4084 1 5008K 00:00:55.55 0.01% run 17:47:00dot1q 4110 1 11772K 00:00:20.46 0.01% run 17:46:59stats 3659 1 8852K 00:01:19.74 0.02% run 17:47:02--More--

% CPU ≥ 0.01

show process | grep option -E ‘[1-9][0-9]{1,2}\...%' % CPU ≥ 10


System demand Processes[local] Ericsson# show process | grep demand

NAME PID SPAWN MEMORY TIME %CPU STATE UP/DOWNisis 0 0 0K Not Avail 0.00% demand 17:17:39rip 0 0 0K Not Avail 0.00% demand 17:17:39igmp 0 0 0K Not Avail 0.00% demand 17:17:39pim 0 0 0K Not Avail 0.00% demand 17:17:39msdp 0 0 0K Not Avail 0.00% demand 17:17:39rsvp 0 0 0K Not Avail 0.00% demand 17:17:39dhcp 0 0 0K Not Avail 0.00% demand 17:17:39mpls_static 0 0 0K Not Avail 0.00% demand 17:17:39ospf3 0 0 0K Not Avail 0.00% demand 17:17:39gsmp 0 0 0K Not Avail 0.00% demand 17:17:39dhelperd 0 0 0K Not Avail 0.00% demand 17:17:39mcastmgr 0 0 0K Not Avail 0.00% demand 17:17:39icrd 0 0 0K Not Avail 0.00% demand 17:17:39snmp 0 0 0K Not Avail 0.00% demand 17:16:51lg 0 0 0K Not Avail 0.00% demand 17:17:39netopd 0 0 0K Not Avail 0.00% demand 17:17:39cspf 0 0 0K Not Avail 0.00% demand 17:17:39clips 0 0 0K Not Avail 0.00% demand 17:17:39cfm 0 0 0K Not Avail 0.00% demand 17:17:39xcd 0 0 0K Not Avail 0.00% demand 17:17:39shm_ribd 0 0 0K Not Avail 0.00% demand 17:17:39


System Stopped Processes[local] Ericsson#

[local] Ericsson#

NAME PID SPAWN MEMORY TIME %CPU STATE UP/DOWN

ospf 0 1 0K Not Avail 0.00% stop 00:00:03

show process ospf

process stop ospf

[local] Ericsson#

[local] Ericsson# show process ospf


ospf 23251 2 5188K 00:00:00.01 0.00% run 00:00:04

process start ospf


critical processes

[local]SSR8020-1# process stop pad

exec_process_command_single: pm_dcl_exec failed with rc: -7118

[local]SSR8020-1# process restart ns


[local]SSR8020-1# process restart cms_server


[local]SSR8020-1# process stop pm

^


[local]SSR8020-1#

› Critical processes on RP like PM, PAD, NS, CMS_SERVER:– Crash of critical process triggers RP switch-over– Critical processes can not be stopped or restarted manually


SSR Process time

[local] Ericsson# show process

Load Average : 0.06 0.01 0.00

NAME PID SPAWN MEMORY TIME %CPU STATE UP/DOWNns 3245 1 5576K 00:00:35.30 0.02% run 17:17:39u2l 3265 1 3864K 00:00:01.24 0.00% run 17:17:39metad 3266 1 30696K 00:00:02.86 0.00% run 17:17:39evtmd 3287 1 4320K 00:00:03.77 0.00% run 17:17:36pnsd 3291 1 4672K 00:00:02.06 0.00% run 17:17:35cmsp_rpswd 3292 1 4348K 00:01:11.77 0.02% run 17:17:35cms_server 3298 1 5336K 00:00:10.74 0.01% run 17:17:35cmsp_ceqa 3300 1 4592K 00:00:13.14 0.00% run 17:17:35cmsp_alsw0 3301 1 4472K 00:00:03.54 0.00% run 17:17:35cmsp_alsw1 3302 1 4468K 00:00:03.54 0.00% run 17:17:35isis 0 0 0K Not Avail 0.00% demand 17:17:39rip 0 0 0K Not Avail 0.00% demand 17:17:39igmp 0 0 0K Not Avail 0.00% demand 17:17:39pim 0 0 0K Not Avail 0.00% demand 17:17:39


Single Process Verification

[local] Ericsson# show process ism

NAME PID SPAWN MEMORY TIME %CPU STATE UP/DOWNism 3634 1 8456K 00:00:09.33 0.00% run 17:48:12


Single Process Verification - ISM

[local] Ericsson# show process ism detail

Process (PID) : ism (3615)

Spawn count : 1

Memory : 8688K

Time : 00:00:30.13

%CPU : 0.01%

State : run

Up time : 2d18h

Heart beat : Enabled

Spawn time : 2 seconds

Max crashes allowed : 5

Crash thresh time : 86400 seconds

Total crashes : 0

Fast restart : DISABLED

Process has not had to be restarted

When did it restart?

PM controls health of the process

Process has not Crashed

No “Last Exit Status” shown


Single Process Verification - OSPF[local] Ericsson# show process ospf detail

Process (PID) : ospf (23251)

Spawn count : 2

Memory : 5364K

Time : 00:00:00.93

%CPU : 0.27%

State : run

Up time : 00:13:36





Total crashes : 0


Last exit status : Kill (9)

Process has had to be restarted

Process has not Crashed

Process was killed manually


What happens when a process crashes?

Process Crash

Core Dump

Process Restarted

Spawn Count incremented

/md


Maximum Crashes Allowed

[local] Ericsson#

Process (PID) : ism (3615)

Spawn count : 1

Memory : 8688K

Time : 00:00:30.13

%CPU : 0.01%

State : run

Up time : 2d18h





Total crashes : 0


show process ism detail

Process allowed to crash maximum of five times in 86400s after which it will not be restarted

Limit on number of crashes allowed

Does not apply to Manual Restarts


service auto-system-recovery

[local] Ericsson#

Context Services:

auto-system-recovery enabled

card-auto-reload enabled

console-break disabled

domain-wildcard disabled

inter-context routing disabled

multiple-contexts enabled

upload-coredump disabled

history-username-display disabled

[local] Ericsson# conf


[local] Ericsson(config)# no service auto-system-recovery

[local] Ericsson(config)# commit

show service

If enabled: non-critical process reaches crash limit RPSW switch-over or reload

If disabled: non-critical process reaches crash limit PM stops the process

service auto-system-recovery

does n0t affect critical process failure RPsw switchover or reload is always initiated

enabled by default


[local] Ericsson#

0..10 Number of Crashes

[local] Ericsson#

[local] Ericsson#

Process (PID) : ospf (3978)

Spawn count : 1

Memory : 5540K

Time : 00:00:59.79

%CPU : 0.19%

State : run

Up time : 15:15:18





Change Maximum number of Crashes Allowed

process set ospf max-crashes ?

show process ospf detail

process set ospf max-crashes 8


[local] Ericsson# show crashfiles

367647 Jun 13 02:29 /md/20120613_022953_vrrpd.3976.1339534793.Ericsson.core.gz

78523 Apr 19 08:21 /md/20120419_152116_login.3684.1334848876.Ericsson.core.gz

896590 Apr 30 10:03 /md/20120430_100347_com.3912.1335805427.Ericsson.core.gz

416136 Mar 22 14:15 /md/20120322_141532_geswd.3611.1332450932.Ericsson.core.gz

422840 Mar 15 12:03 /md/20120315_120343_pm_1881_com_4069.core

455869 Apr 10 15:26 /md/20120410_152641_tsmrp.3663.1334096801.Ericsson.core.gz

798498 Mar 29 14:02 /md/20120329_140240_com.4119.1333054960.Ericsson.core.gz

382844 Mar 29 18:25 /md/20120329_182510_arpd.3667.1333070710.Ericsson.core.gz

403591 Mar 29 19:13 /md/20120329_191353_geswd.3524.1333073633.Ericsson.core.gz

Crash files


Manual Core Dumps

Sometimes we may force a core dump

/md

Process Core Dump

Before Restarting a Process Core Dump


Manual Core Dump Execution

/md

Process Core DumpPM

ldp

ppp

pim

isis

ospf

System Processes

Heartbeat

[local] Ericsson#

[local] Ericsson#

[local] Ericsson#

[local] Ericsson#

[local] Ericsson# dir /md

process set ppp heart-beat off

process coredump ppp

process coredump ppp no-restart

process set ppp heart-beat on


Monitoring Processes

[local] Ericsson#

monitor process ospf


ospf 3978 1 5540K 00:01:03.25 0.12% run 16:08:06

% enter ctrl-C to exit monitor mode, monitor duration(sec): 600 (00:00:06)


ospf 3978 1 5540K 00:01:03.26 0.10% run 16:08:14

% enter ctrl-C to exit monitor mode, monitor duration(sec): 600 (00:00:14)

Information Updated in real time

Enter Ctrl-c to exit monitor mode

SSR RPSWSSR Troubleshooting


Basic RPSW Checks

[local] Ericsson# show version

Ericsson IPOS Version IPOS-12.1.109.2.66-Release

Built by sysbuild@SWB-node18 Wed May 30 13:10:13 PDT 2012

Copyright (C) 1998-2012, Ericsson AB. All rights reserved.

Operating System version is Linux 2.6.32.53-798-g5652359

System Bootstrap version is OpenFirmware 3.0.1.12 PRODUCTION RELEASE

Installed minikernel version is v2.6.32.46-738-g33cd07b-3072320

Router Up Time - 1 day, 17 hours 35 minutes 50 seconds


RPSW Process Health Checks

[local] Ericsson# show system status

System Status: OK

[local] Ericsson# show process diagnose

Current time: Thu Jun 14 23:31:58 2012

Diagnostics for aaad: no issues

Could not get diagnostics for atm

Could not get diagnostics for clips

Could not get diagnostics for dhcp

Could not get diagnostics for dhelperd

Could not get diagnostics for dhcpv6d

Could not get diagnostics for dhelperv6d

no issues

Diagnostics for flowd: no issues

Could not get diagnostics for ipfix

Diagnostics for ism: no issues

no issues


Accessing RPSW linux Shell

[local] Ericsson# start shell

sh-3.2#

eth0 Link encap:Ethernet HWaddr D0:F0:DB:08:88:00

inet addr:10.1.1.130 Bcast:10.1.1.255 Mask:255.255.255.0

inet6 addr: fe80::d2f0:dbff:fe08:8800/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX bytes:14355202 (13.6 MiB) TX bytes:2656853 (2.5 MiB)

ethMate0 Link encap:Ethernet HWaddr 02:00:00:02:FC:01


inet6 addr: fe80::ff:fe02:fc01/64 Scope:Link

UP BROADCAST RUNNING MASTER MULTICAST MTU:9216 Metric:1


…

IPOS runs on top of a Linux Platform

Normal Linux Command can be executed

ifconfig

on rp: Both eth mgmt on front panel and internal INTERFACEs visible from linux shell


Capturing traffic on shell-visible interfaces

sh-3.2# tcpdump -i eth0tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes

00:37:36.934363 IP 10.1.1.130.telnet > 10.1.1.1.37296: P 923518176:923518323(147) ack 1376373802 win 23 <nop,nop,timestamp 175467468 2346778671>

00:37:36.934489 IP 10.1.1.1.37296 > 10.1.1.130.telnet: . ack 147 win 1002 <nop,nop,timestamp 2346778676 175467468>










…




00:37:38.374242 IP 10.1.1.1.37296 > 10.1.1.130.telnet: P 1:2(1) ack 88835 win 1002 <nop,nop,timestamp 2346779038 175467828>

^C

723 packets captured

723 packets received by filter

0 packets dropped by kernel

capturing on eth0: mgmt interface

capturing on interface not-visible in linux shell requires port mirroring!!!


control plane interfaces on RP cardRPSW1 Active

GE SwitchALSW1(A)

10 GE

1GEMAC

LC

ethSw0

alternate link

default link

Linux Interfaces on RP:

1) Physical Interfaces:

a. ethSw1 to ALSW1

b. ethSw2 to ALSW2

No IP address

2) Bonding Interface:

a. ethSw0 logical interface on ethSw1 and ethSw2

b. IP address: • 127.3.252.1 on RPSW1

• 127.3.253.1 on RPSW2

• 127.3.254.1 when Active:

“Well-known Address”

c. unicasts to both ethSw1 and ethSw2 for redundancy

10 GE

1 GE

RPSW2 Standby

ethSw0

ethSw1 ethSw1 ethSw2ethSw2

GE Switch ALSW2(B)

Bonding127.3.252.1127.3.254.1 (when Active)

Bonding127.3.253.1127.3.254.1 (when Active)

LP

Ethernet path: rpsw Active (127.3.254.1) to Line card (127.3.Slot#.1)


control plane redundancysh-3.2# ifconfig

ethSw0 Link encap:Ethernet HWaddr 02:00:00:01:FC:01




RX packets:1861408 errors:0 dropped:0 overruns:0 frame:0

TX packets:3252916 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0



UP BROADCAST RUNNING SLAVE MULTICAST MTU:9582 Metric:1










RX bytes:0 (0.0 b) TX bytes:170508587 (162.6 MiB)

1+1 Control Plane Redundancy



a. ethMate0 logical interface on ethMate1 and ethMate2

b. IP address:

• 127.4.252.1 on RPSW1

• 127.4.253.1 on RPSW2

c. Unicasts to either ethMate1 or ethMate2

interfaces to standby RP card

1 GE

Linux Interfaces on RP:


a. ethMate1 to peer RP

b. ethMate2 to peer RP

No IP address

1 GE

Ethernet path: rpsw1 (127.4.252.1) to RPSW2 (127.4.253.1)

RPSW1 RPSW2

ethMate1

ethMate2

ethMate0

Bonding127.4.252.1

Bonding127.4.253.1

ethMate0

ethMate1

ethMate2

sh-3.2#

Trying 127.4.253.1...

Connected to 127.4.253.1.

Escape character is '^]'.

login: user

Password:

[local]standby#

telnet 127.4.253.1


control plane redundancysh-3.2# ifconfig















Memory:d0100000-d0180000






RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Memory:d0000000-d0080000


TOP Process from shell[local] Ericsson# start shell

sh-3.2#

top - 02:14:24 up 23 days, 15:30, 0 users, load average: 0.06, 0.10, 0.07Tasks: 184 total, 1 running, 183 sleeping, 0 stopped, 0 zombieCpu(s): 0.2%us, 0.0%sy, 0.0%ni, 99.6%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%stMem: 24555924k total, 1439732k used, 23116192k free, 138460k buffersSwap: 0k total, 0k used, 0k free, 547992k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3273 root 20 0 92544 5600 3088 S 0.3 0.0 17:01.97 nameserver 3331 root 20 0 137m 4340 3176 S 0.3 0.0 38:06.71 cmsp_rpswd 3632 root 20 0 132m 10m 4508 S 0.3 0.0 4:08.15 ism2 3995 root 20 0 415m 25m 18m S 0.3 0.1 7:25.01 com17201 root 20 0 19000 1256 892 R 0.3 0.0 0:00.37 top 1 root 20 0 21180 2440 1020 S 0.0 0.0 0:18.92 rbn_init 2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd 3 root RT 0 0 0 0 S 0.0 0.0 0:00.01 migration/0 4 root 20 0 0 0 0 S 0.0 0.0 0:04.07 ksoftirqd/0 5 root RT 0 0 0 0 S 0.0 0.0 0:00.09 watchdog/0 6 root RT 0 0 0 0 S 0.0 0.0 0:01.30 migration/1 7 root 20 0 0 0 0 S 0.0 0.0 0:03.37 ksoftirqd/1 8 root RT 0 0 0 0 S 0.0 0.0 0:00.10 watchdog/1

top

List of most CPU- intensive tasks

Updated in Real Time


RPSW Redundancy Troubleshooting

[local] Ericsson#

---------------------------------

This RPSW is active

---------------------------------

STANDBY RPSW READY? : YES

PAd in sync? : YES

Database in sync? : YES

Software Release in sync? : YES

Firmware in sync? : YES

Mate-to-Mate link up? : YES

ARP SUCCESS

CLS-ISSU-CHKPT-NAME SUCCESS

CSM SUCCESS

ISM SUCCESS

…

RPSW Switchover History:

------------------------

[Wed Aug 1 23:31:01 2012] User Requested Manual Switch : (RPSW2)->(RPSW1)

show redundancy

Standby RP is ready

Standby RP synched with Active RP

List of Processes Synched

Details of RP switchovers occurred since system reload


RPSW RELOAD SWITCHOVERS [local] Ericsson#

The "reload switch-over" command on this system will cause

standby to active switch over, some cards may be rebooted

Do you really want to reload? (y/n) n

[local]SSR8020#

sh-3.2# ps aux | grep pm

root 3217 7328 Jul09 30:45 /usr/lib/siara/bin/pm

sh-3.2# kill -9 3217

sh-3.2# Connection closed by foreign host.

[local]SSR8020# show redundancy

…

…

…


------------------------


[Thu Aug 2 05:42:51 2012] Card Failed : (RPSW1)->(RPSW2)

reload switch-over Manual switch-over

Crash of critical process causes RP to reload, e.g.: PM, PAD, NS, CMS_SERVER

Process PM abnormal termination triggers failover

Automatic failover upon failure of the Active RP

start shell


Show System Redundancy[local] Ericsson#

…


------------------------


[Thu Aug 2 05:42:51 2012] Card Failed : (RPSW1)->(RPSW2)

…

| Active's Version | Standby's Version

___________|_____________________________|_________________________________

Firmware | OpenFirmware 3.0.1.12 | OpenFirmware 3.0.1.12

| PRODUCTION RELEASE | PRODUCTION RELEASE

___________|_____________________________|_________________________________

Software | /p01: 12.1.109.3 | /p01: 12.1.109.3

___________|_____________________________|_________________________________

Diagnostic | /p01: 12.1.109.3 | /p01: 12.1.109.3

___________|_____________________________|_________________________________

Minikernel | v2.6.32.46-738-g33cd07b-3072| v2.6.32.46-738-g33cd07b-3072

show system redundancy


Show redundancy[local] Ericsson#

Server (sync version3.0) is up

Client (sync version3.0) is connected

Client Mode: Service

| Active's Version | Standby's Version

___________|_____________________________|_____________________________

Firmware | OpenFirmware 3.0.1.12 | OpenFirmware 3.0.1.12

| PRODUCTION RELEASE | PRODUCTION RELEASE

___________|_____________________________|_____________________________

Software | /p01: 12.1.109.2.66 | /p02: 12.1.109.2.66

___________|_____________________________|_____________________________

Diagnostic | /p01: 12.1.109.2.66 | /p02: 12.1.109.2.66

___________|_____________________________|_____________________________

Minikernel | v2.6.32.46-738-g33cd07b-3072| v2.6.32.46-738-g33cd07b-3072

| 320 | 320

___________|_____________________________|_____________________________

show redundancy detail


Show redunDancy continued[local] Ericsson#

<CONTINUED>

Software Sync Log:

------------------

Release Sync Type: release sync unnecessary

Jun 13 2012 05:32:07: UNNECESSARY

Jun 13 2012 05:32:07: SUCCESS

Configuration Files Sync Log:

-----------------------------

Jun 14 2012 03:25:27: SUCCESS

show redundancy detail

Configuration files on the two RP’s are kept in synch


[local] Ericsson#

---------------------------------

This RPSW is active

---------------------------------

STANDBY RPSW READY? : NO

PAd in sync? : NO

Database in sync? : NO

Software Release in sync? : NO

Firmware in sync? : NO

Mate-to-Mate link up? : NO

During RPSW Booting[local] Ericsson#

Current platform is SSR 8020

(Flags: A-Active Card B-Standby Card)

Slot : Configured Type Installed Type Operational State Flags

--------------------------------------------------------------------------

RPSW1 : n/a rpsw IS A

RPSW2 : n/a rpsw OOS-Booting B

.

show chassis

show redundancy

during boot-up: Standby rp still not ready and synched


Line

Card Line

Card

CLI, SNMP, other

ConfigProcess

Database

OSPF


MulticastBGP Static

OS Kernel

Process Manager

PPP

CLI, SNMP, other

ConfigProcess

Database

OSPF


MulticastBGP Static

OS Kernel

Process Manager

PPP

Active RPSW Standby RPSW

Analyzing Standby RPSW

1) Problem Occurs in Active RP

• E.g. Crash of critical process like PM

• E.g. Hardware Failure

Reload Switch-over: Active RP reloads, Standby RP becomes Active RP

Active ALSW

2) Previous Active RP comes back up

• Preious Active RP is now standby RP

• Done completely automatically


Line

Card Line

Card

CLI, SNMP, other

ConfigProcess

Database

OSPF


MulticastBGP Static

OS Kernel

Process Manager

PPP

CLI, SNMP, other

ConfigProcess

Database

OSPF


MulticastBGP Static

OS Kernel

Process Manager

PPP

Standby RPSW Active RPSW

RELOAD

may need to debug stanby rp


[local]Ericsson#

sh-3.2# telnet rpsw2

Trying 127.3.253.1...

Connected to rpsw2.


login: user

Password:

[local]standby#

Accessing Standby RPSW[local] Ericsson#

Trying 127.2.253.1...

Connected to 127.2.253.1.


login: user

Password:

[local]standby#

telnet mate

Console

Management

Active Standby

start shell


Crash files on switchover[local]SR1-1# show chassis


...


--------------------------------------------------------------------------


RPSW2 : n/a rpsw IS B

ALSW1 : n/a alsw IS A

...

[local]SR1-1# show crashfiles

624241 Mar 27 13:13 /md/20120327_131307_clsd.6154.1332853987.Redback.core.gz

1079703 Jun 12 00:11 /md/20120612_001100_lc_dtpd.1731.1339459859.lc-5.core.gz

399221 Aug 1 01:40 /md/20120801_014041_pppd.3908.1343785241.SSR8020.core.gz


632560 Jun 6 04:34 /md/20120606_043404_netopd.4128.1338957244.SSR8020.core.gz


1265367 Jun 5 00:19 /md/20120605_001911_rcm.2980.1338855551.SSR8020.core.gz

[local]standby# show crashfiles

[local]standby#

before switchover

7 crash files on active rp

no crash files on standby rp

On Switchover Core Dump files moved to new Active RP

All Core dump files visible on new Active RP


Crash files on switchover continued[local]SR1-1# show chassis


...


--------------------------------------------------------------------------




...

[local]SR1-1# show crashfiles



1079703 Jun 12 00:11 /md/20120612_001100_lc_dtpd.1731.1339459859.lc-5.core.gz

624241 Mar 27 13:13 /md/20120327_131307_clsd.6154.1332853987.Redback.core.gz

1265367 Jun 5 00:19 /md/20120605_001911_rcm.2980.1338855551.SSR8020.core.gz


632560 Jun 6 04:34 /md/20120606_043404_netopd.4128.1338957244.SSR8020.core.gz

[local]standby# show crashfiles

[local]standby#

after switchover

7 crash files on new active rp

no crash files on old active rp


Active RPSW Crash Troubleshooting example[local]SR1-2# sh redundancy

…


------------------------

[Sat Jun 16 04:01:07 2012] Card Failed : (RPSW1)->(RPSW2)

[local]SR1-2# sh crashfiles

1128965 Jun 16 04:00 /md/20120616_040050_pad.3340.1339799450.SR1-2.core.gz

[local]SR1-2# sh log | grep pad

Jun 16 03:56:27.093: %LOG-4-NOINIT: pad (pid 3319) logged 3826780032 msgs prior t

o initializing logger. Last event code: 0x0

Jun 16 03:56:43.256: %PM-6-INFO: pm_send_status: Notifying pad

Jun 16 04:00:56.735: %LOG-6-PRI_ACTIVE: Jun 16 04:00:56.734: %PM-0-EMERG: Critical

process 'pad' has died.

SSR Line cardsSSR Troubleshooting


Line card States[local]Ericsson#


(Flags: A-Active Card B-Standby Card)


--------------------------------------------------------------------------




ALSW2 : n/a alsw IS B

SW1 : n/a sw IS

SW2 : n/a sw IS

SW3 : n/a sw IS

SW4 : n/a sw IS

1 : ge-40-port ge-40-port IS

2 : 10ge-10-port none n/a

3 : none 10ge-10-port OOS-NotActivated

4 : none none n/a

show chassis


configuring a line card[local]SR1-1(config)# card 10ge-10-port 4

[local]SR1-1(config-card)# commit

Transaction committed.

[local]SR1-1(config-card)#show chassis


…


--------------------------------------------------------------------------

…

SW2 : n/a sw IS

SW3 : n/a sw IS

SW4 : n/a sw IS

1 : ge-40-port none n/a


3 : none ge-40-port OOS-NotActivated

4 : 10ge-10-port none n/a

5 : 10ge-10-port 10ge-10-port IS


unconfigure a line card[local]SR1-1(config)# no card 10ge-10-port 4

[local]SR1-1(config)# commit


[local]SR1-1(config)# show chassis


…


--------------------------------------------------------------------------

…

SW2 : n/a sw IS

SW3 : n/a sw IS

SW4 : n/a sw IS



3 : none ge-40-port OOS-NotActivated

4 : none none n/a

5 : 10ge-10-port 10ge-10-port IS


LiNe Card States

Out of Service - OOSIn Service - IS

Line Card States

- IS

- IS Degraded

- OOS Not Activated

- OOS Booting

- OOS INIT

- OOS OSD

- OOS Shutdown

- OOS Fault

A card has to be in IS state to carry traffic


Boot Process

OOS-Fault

OOS-INIT

OOS-Booting

OOS-Not Activated

OOS-OSD

IS



card ge-40-port 1

commit

Card Admission Procedure

OFW Loaded, POD, Kernel Booted

IPC Functional, Critical Processes Started

State Timer Expires

OOS Diagnostic Image Loaded


Boot Process continued

OOS-Fault

OOS-INIT

OOS-Booting

OOS-Not Activated

IS-Degraded

OOS-OSD

IS


[local] Ericsson(config-card)#

[local] Ericsson(config-card)# commit

[local] Ericsson(config-card)#no deactivate

card ge-40-port 1

deactivate

OFW Loaded, POD, Kernel Booted

IPC Functional, Critical Processes Started

Critical Alarm

Major Alarm

Card reload

OOS Diagnostic Image Loaded

OOS-Shutdown

[local]SR1-1(config-card)#shutdown

[local]SR1-1(config-card)#commit

[local]SR1-1(config-card)#no shutdown

[local]SR1-1#reload card 3

The "reload" command will restart the card in slot 3

Do you really want to reload? (y/n)


Accessing Line Card Shell

[local] Ericsson#

sh-3.2#

root@lc-0's password:

Wind River Linux glibc_std (standard) 3.0

root@lc-1[1]:/root>

Connection to lc-0 closed.

sh-3.2#

[email protected]'s password:


root@lc-1[1]:/root>

start shell

ssh lc-0

exit

Up to IPOS 12.1:

Zero Based Numbering!

Line Card 1 = lc-0

IPOS runs on top of a Linux Platform No CLI on Line Card: only Linux shell

Internal IP addresses:

127.3.S.1

S=0 to 19

S is the Slot#

ssh [email protected]


Accessing Line Card Shell

sh-3.2$

root@lc-1's password:

Last login: Tue Nov 20 16:54:13 2012 from rpsw2


root@lc-1[1]:/root>

Connection to lc-1 closed.

sh-3.2$

[email protected]'s password:

Last login: Tue Nov 20 16:56:46 2012 from rpsw2


root@lc-1[1]:/root>

ssh root@lc-1

exit

From IPOS 12.2:

Line Card 1 = lc-1

Internal IP addresses:

127.3.S.1

S=0 to 19

S is the Slot#

ssh [email protected]


Accessing Line Card Shellroot@lc-1[1]:/root>

eth0 Link encap:Ethernet HWaddr 02:00:00:01:00:01






Base address:0xc000







ethSw0 Link encap:Ethernet HWaddr 02:00:00:01:00:01


inet6 addr: fe80::ff:fe01:1/64 Scope:Link

ifconfig


Accessing Line Card Shell- continued






ethSw0.1 Link encap:Ethernet HWaddr 02:00:00:01:00:01








lc0 Link encap:Ethernet HWaddr 00:00:00:00:00:00

UP BROADCAST RUNNING NOARP MULTICAST MTU:18024 Metric:1




Accessing Line Card Shell- continued



lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.255.255.0

inet6 addr: ::1/128 Scope:Host

UP LOOPBACK RUNNING MTU:16436 Metric:1




RX bytes:2536 (2.4 KiB) TX bytes:2536 (2.4 KiB)

xcrp Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:18024 Metric:1




RX bytes:5443002 (5.1 MiB) TX bytes:0 (0.0 b)

only internal INTERFACEs used on control plane visible from shell

I/O ports on front panel not visible from linux shell


root@lc-3[3]:/root>

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on ethSw0, link-type EN10MB (Ethernet), capture size 96 bytes

03:29:38.587349 IP lc-2.ssh > rpsw2.48374: P 2847430686:2847430878(192) ack 2885279581 win 1450 <nop,nop,timestamp 16202854 36667316>

03:29:38.587398 IP rpsw2.48374 > lc-2.ssh: . ack 192 win 837 <nop,nop,timestamp 36667317 16202854>








…



^C

100 packets captured

103 packets received by filter

0 packets dropped by kernel

Capturing traffic on shell-visible interfaces

capturing on internal interface: ethsw0

capturing on interfaces not-visible in linux shell requires port mirroring!!!

tcpdump -i ethSw0


control plane interfaces on line card

RPSW Active

10 GEController

CPU

GE SwitchALSW1 (A)

10 GE

NPU LP

1GEMAC

LC

GE Switch ALSW2 (B)

1 GE

eth0 eth1

ethSw0

Bonding127.3.S.1S=0 to 19S is the Slot#

alternate linkdefault link

Linux Interfaces on LC:


a. eth0 to ALSW1

b. eth1 to ALSW2

No IP address


a. ethSw0 logical interface on eth0 and eth1

b. IP address: 127.3.S.1

c. unicasts to both eth0 and eth1 for redundancy

10 GE

1 GE

Ethernet path: Line card (127.3.Slot#.1) to RPSW (127.3.254.1)


control plane redundancyroot@lc-5[5]:/root> ifconfig







Base address:0xc000






RX bytes:0 (0.0 b) TX bytes:38047095 (36.2 MiB)

ethSw0 Link encap:Ethernet HWaddr 02:00:00:01:04:01








1+1 Control Plane Redundancy


[local] Ericsson#

Aug 16 09:49:07: %CMS-6-INFO: 3384/cmsp_cmbhub_lc_cint_status_handle(1732) slot_id(1): lp mailbox 0x10, desc: "Booting OFW Primary", cmb_ret 0

Aug 16 09:49:40: %CMS-6-INFO: 3384/cmsp_cmbhub_lc_cint_status_handle(1732) slot_id(1): lp mailbox 0x11, desc: "Booting Kernel", cmb_ret 0

Aug 16 09:50:14: %CMS-6-INFO: 3384/cmsp_cmbhub_lc_cint_status_handle(1732) slot_id(1): lp mailbox 0x80, desc: "Init proc entered", cmb_ret 0

Boot Progression

show log | grep slot_id(1) | grep “lp mailbox”

Line Card Slot#

command run from cli on rp


Line Card Processes[local]Ericsson#

--------------------------------------------------------------

Slot number : 1/LP

Card Type : ge-40-port

Load Average : 0.11 0.07 0.01


ns 1730 1 4448K 00:02:19.08 0.00% run 2d07h

dlm 1742 1 4416K 00:00:11.72 0.00% run 2d07h

metad 1781 1 30324K 00:00:16.03 0.00% run 2d07h

pnsd 1826 1 4036K 00:00:15.72 0.00% run 2d07h

lc_wdog 1782 1 3364K 00:00:06.76 0.00% run 2d07h

cmsp_lc 1783 1 3904K 00:00:42.76 0.00% run 2d07h

np4_ald 1787 1 88848K 00:13:01.59 0.00% run 2d07h

fabricd 1788 1 10972K 00:00:18.59 0.00% run 2d07h

sh process card 1


Service card-auto-reload

› Crash of critical process on RP causes RP to reload, e.g.: PM, PAD, NS, CMS_SERVER› Crash of critical process on LC causes LC to reload:

– All FABL processes– ALD process

› SERVICE CARD-AUTO-RELOAD:– if configured, card is reloaded when critical process killed or crashes– if not configured, card doesn’t reload and goes into IS-Degraded state– automatic reload is enabled by default

[local]pipd-ssr-81(config)#service card-auto-reload

[local]pipd-ssr-81(config)#show service

Context Services:

auto-system-recovery disabled

card-auto-reload enabled

console-break enabled

…


connection to switch fabric

Line Cards Smart ServiceCards

Switch Fabric+

Alarms & Timing

Switch Fabric+

Route Processor

Switch Fabric+

Route Processor

Switch Fabric+

Alarms & Timing

Switch Fabric

Switch Fabric

Switch Fabric

Switch Fabric

SERDES Links

Line Cards

SSR 8020: 8 sw cards

32 SERDES Links for each LC


Serdes[local] Ericsson#

Displaying Fabric Link Connectivity :

Fabric-ID = 0x2, LC-Slot = LC01, Device-Instance = 0, Device-Status = UP

-------------------------------------------------------------------------

Src-Serdes# SW-Slot# Dest-Device-Id# Dest-Serdes# LinkStatus

-------------------------------------------------------------------------

00 RPSW2 00 87 UP

01 RPSW2 00 89 UP

02 RPSW1 00 84 UP

03 RPSW1 00 93 UP

04 ALSW2 00 87 UP

05 ALSW2 00 89 UP

06 ALSW1 00 84 UP

07 ALSW1 00 93 UP

08 RPSW2 00 43 UP

…

25 SW3 00 41 UP

26 SW4 00 42 UP

27 SW4 00 43 UP

28 SW2 00 43 UP

29 SW2 00 42 UP

30 SW1 00 41 UP

31 SW1 00 40 UP

show card 1 fabric-link

32 Serdes from each LC

SSR Fan Trays and Power Modules

SSR Troubleshooting


SSR Power modules


Power Modules

250A

BU

S

Power Back Plane

Power Backplane

System Backplane

I2C Bus to RP

Input Redundancy Output Redundancy: 7 + 1

PM1

PM1

PM1

PM1

PM1

PM1

PM1

PM1

Primary Feed

Secondary Feed

Primary Feed

Secondary Feed

Primary Feed

Secondary Feed

Primary Feed

Secondary Feed

Primary Feed

Secondary Feed

Primary Feed

Secondary Feed

Primary Feed

Secondary Feed

Primary Feed

Secondary Feed

RPSW

ALSW

SW

Fan Tray

Line Card 1

Line Card 2

Line Card 20


Power allocationPlatform Administration Daemon Process is in charge of Power Management

Power Budget is checked before bringing up Cards

• Card will not be activated if insufficient Power

• Power Budget Calculations based on maximum Power Specification for component

• Additional power Resources will trigger activation


Power Related Alarms 1: MINOR

show system alarm[local] Ericsson#


--------------------------------------------------------------------------------

Jun 13 05:30:04.841 PM1 Minor Input Failure - Feed A



--------------------------------------------------------------------------------

Jun 13 05:30:04.841 PM1 Minor Input Failure - Feed B

PM1

Feed B

Feed A

PM1

Feed B

Feed A


Power Related Alarms 2: minorshow system alarm[local] Ericsson#


--------------------------------------------------------------------------------

Jun 13 05:30:04.841 PM5 Minor Input Failure - Both Feeds



--------------------------------------------------------------------------------

Jun 13 05:30:04.841 PM7 Minor Power Module Unreachable Alarm



--------------------------------------------------------------------------------

Jun 13 05:30:04.841 PM6 Minor Power Module Missing

PM1

Feed B

Feed A

RPSW

PM1

PM5 PM7 PM8PM1 PM2 PM3 PM4


Power Related Alarms 3: critical



--------------------------------------------------------------------------------

Jun 13 05:30:04.841 1 Critical Out-of-service Insufficient Power


[local] Ericsson#

FRU type Min Load (W) Max Load (W)

------------------------------------------------------

rpsw 100 168

alsw 15 55

sw 5 40

ge-40-port 3 280

10ge-10-port 3 400

ssc1 15 400

ft 100 900

System Power INformaTionshow chassis power[local] Ericsson#

Physical Capacity: 7800 W (at 60A) Physical Capacity: 7800 W (at 60A)

Requested Load: 3260 W Allocated Load: 3260 W

-------------------------- --------------------------

Requested Net: 4540 W Allocated Net: 4540 W

show chassis power inventory


Power Module informationshow hardware power-module pm1 detail[local] Ericsson#


Serial No : BR81691974 Hardware Rev : R2B

Mfg Date : 05-NOV-2011

Hardware Status : OK POD Status : Passed

Input Feed A Volts : -54 V Input Feed B Volts : +0 V

PM IN OK LED : On PM DC LED : On


Power on Diagnostic


SSR Cooling Airflow

CardsRear of ChassisFront of Chassis

Fan 1

Fan 2

Chassis Intake

PEM Intake PEM Exhaust

Chassis Exhaust


SSR Fan Tray

Six high speed, high performance fans

Below 50 Degrees Celsius

Single fan failure redundancy

RPSW

Fan Tray

System Power-on

Full Speed

I2C Bus to RP

RPSW

Fan TrayFull Speed

RP queries Fan Tray


[local] Ericsson#

FT1..FT2 Fantray slot number

detail Display detail hardware information

thermal Display hardware thermal information

| Output Modifiers

<cr>

[local] Ericsson# show hardware fantray

Slot Type Serial No Rev Mfg Date Payload

----- -------------------- -------------- ------- ----------- -------

FT1 ft ce510004an r2c 25-NOV-2011 N/A

FT2 ft ce510004ah r2c 25-NOV-2011 N/A

show hardware fantray ?

SSR Fan Tray Information


[local] Ericsson#



[local] Ericsson# show hardware fantray FT1 detail


Serial No : ce510004an Hardware Rev : r2c

EEPROM id/ver : 0x20/1 Mfg Date : 25-NOV-2011

Firmware : 0x---

Set Speed : LOW Card Temp Status : Normal

Hardware Status : OK POD Status : Passed

Fan 1 : 2898 rpm Fan 2 : 2898 rpm

Fan 3 : 2967 rpm Fan 4 : 2898 rpm

Fan 5 : 2967 rpm Fan 6 : 2967 rpm

OK LED : On


show hardware fantray FT2 thermal

Fan Tray show commands

Power on Diagnostic

Fans Speed


Fan Tray Alarms



--------------------------------------------------------------------------------

Jun 13 05:30:04.841 FT1 Major Fan Tray Missing



--------------------------------------------------------------------------------

Jun 13 05:30:04.841 FT1 Minor Fan Tray Not Recognized RPSW

FT1

FT1

FT2

?


[local] Ericsson# show system alarm


--------------------------------------------------------------------------------

Jun 13 05:30:04.841 FT1 Minor Fan Tray Hardware Failure

[local] Ericsson# show system alarm


--------------------------------------------------------------------------------

Jun 13 05:30:04.841 FT1 Minor Fan Tray Unreachable

Fan Tray Alarms

RPSW

RPSW

FT1

FT1


Thermal Checksshow hardware card 1 thermal[local] Ericsson#

Slot : 1 Type : ge-40-port


Sensor 1 : Normal (26 C) Sensor 2 : Normal (28 C)



Sensor 7 : Normal (26 C)

[local]SSR8020# show hardware backplane thermal

Slot : N/A Type : backplane


[local]SSR8020# show hardware power-module pm2 thermal



SSR Log FilesSSR Troubleshooting


System logging introduction› Troubleshooting:

– Often after problem occurred

› Logs: historical information› System logger: collects information

from multiple sources› Storage of log messages

– /md/loggd_dlog.bin

Systemlogs

Troubleshooting

?


Loggd Process

Logger Daemon (Loggd)

LOG Debug MAL PKT

1 Mb Buffer

Active RPSW

STANDBY

RPSW

Line Card


severity level description

System log commands

Looking at current log events[local]Ericsson# show logNov 20 08:22:53: %IPC-3-ERR: loggd: ipc_sendto sendto errno 2: No such file or directoryNov 20 08:22:53: %IPC-3-ERR: loggd: sendSync: sendtoNov 20 08:22:53: %IPC-3-ERR: loggd: ipc_sendto sendto errno 2: No such file or directoryNov 20 08:22:53: %IPC-3-ERR: loggd: ipcSendCommon: sendto rc=-3Nov 20 08:22:53: %IPC-3-ERR: loggd: ipcContactPM: ipcSend(NS) err=-16Nov 20 08:22:54: %ISP-6-INFO: [isp_heartbeat_register] is called on ACTIVE-more--

0 Emergencies

1 Alerts

2 Critical

3 Errors

4 Warnings

5 Notifications

6 Informational

7 Debugging

SeverityTimestampapplication Log Message

[local]Ericsson# show log card ?

1..20

RPSW1..RPSW2 slot number

all all slots

[local]Ericsson#

`


logs from other cards[local]Ericsson# show log startup

Ericsson Log Ericsson IPOS Context ID 0x40080001Aug 19 16:47:17: {3/LP}: %FABRICD-6-INFO: Enable WLCFAP IRQ.Aug 19 16:47:17: {3/LP}: %FABRICD-6-INFO: Enable FAP.0 IRQ.Aug 19 16:47:17: {3/LP}: %FABRICD-6-INFO: IPC Event: FAPFMA_EVENT_IPC_FMM_BIRTHAug 19 16:47:19: %PAD-6-INFO: SVC - proc_asgSl_card_boot_events():885: slot 3, ASG_SL_CARD_INIT_PASSED received

Aug 19 16:47:19: %PAD-6-INFO: SVC - slMakeEvent_asg_cb():504: slot 3, Card_Boot_Event :6, image 0, source:1

Aug 19 16:47:19: %PAD-6-INFO: Card activation completed on slot 3Aug 19 16:47:19: {3/LP}: %FABRICD-6-INFO: Sync Type: FAPFMA_FMR_SYNCAug 19 16:47:19: {3/LP}: %CAD-6-INFO: caCdlNpuUpdateInitPhase: All drivers have completed initialization. Making transition to Ready.

[local]Ericsson(config)# logging ? active Configure to log active event to standby controller bsd-syslog Configure to log bsd syslog events cct-valid Configure to log only event with valid cct debug Configure to log debug events events Configure event log parameters standby Configure to log standby event to active controller syslog-server Configure to behave as a syslog server timestamp Configure the timestamp information of log

line cards send logs to active rp by default

Active and Stanby rp can send each others logs


Show log and time[local]Ericsson# show log active all since 2012:06:23:21:54:17Jun 23 21:54:35.086: %PAD-6-INFO: virtual bool PktBaseEPortMgr::setPortOperation(EnableDisable): Port 1/14, enableDisable=ENABLE

Jun 23 21:54:35.086: %PAD-6-INFO: caPktPortEnable(1/14)Jun 23 21:54:35.195: %APP-6-INFO: submitting alarm, major: 193, minor: 1, dn: ManagedElement=1,Equipment=1,Slot=0,Port=13, severity: 3, text: Link down , time: 1340468651 (in applibcm_svr_cfg_event_callback)

Jun 23 21:54:35.807: %CSM-6-PORT: ethernet 1/14 link state UP service state UP, overall admin is UP

Jun 23 21:54:35.811: [0002]: %VRRP-5-STATE_CHANGE: VRRP router SS7_vrrp_1/151 state change from Init to Backup due to event Interface Up

Jun 23 21:54:35.811: [0003]: %VRRP-5-STATE_CHANGE: VRRP router sr_om_1_sw01/150 state change from Init to Backup due to event Interface Up

Jun 23 21:54:35.811: [0004]: %VRRP-5-STATE_CHANGE: VRRP router SR_GB_1_Sr1/10 state change from Init to Backup due to event Interface Up

Jun 23 21:54:38.201: %APP-6-INFO: submitting alarm, major: 193, minor: 1, dn: ManagedElement=1,Equipment=1,Slot=0,Port=13, severity: 0, text: Link down , time: 1340468677 (in applibcm_svr_cfg_event_callback)


Show log and time[local]Ericsson# show log active all since 2012:06:23:21:54:17 until 2012:06:23:21:55

Jun 23 21:54:35.086: %PAD-6-INFO: virtual bool PktBaseEPortMgr::setPortOperation(EnableDisable): Port 1/14, enableDisable=ENABLE

Jun 23 21:54:35.086: %PAD-6-INFO: caPktPortEnable(1/14)Jun 23 21:54:35.195: %APP-6-INFO: submitting alarm, major: 193, minor: 1, dn: ManagedElement=1,Equipment=1,Slot=0,Port=13, severity: 3, text: Link down , time: 1340468651 (in applibcm_svr_cfg_event_callback)


Jun 23 21:54:35.811: [0002]: %VRRP-5-STATE_CHANGE: VRRP router SS7_vrrp_1/151 state change from Init to Backup due to event Interface Up

Jun 23 21:54:35.811: [0003]: %VRRP-5-STATE_CHANGE: VRRP router sr_om_1_sw01/150 state change from Init to Backup due to event Interface Up

Jun 23 21:54:35.811: [0004]: %VRRP-5-STATE_CHANGE: VRRP router SR_GB_1_Sr1/10 state change from Init to Backup due to event Interface Up

Jun 23 21:54:38.201: %APP-6-INFO: submitting alarm, major: 193, minor: 1, dn: ManagedElement=1,Equipment=1,Slot=0,Port=13, severity: 0, text: Link down , time: 1340468677 (in applibcm_svr_cfg_event_callback)


Active RPSW STANDBY

RPSW

Line Card

Log Files Explained

› /md/loggd_dlog.bin

LOG Logger Daemon Restarts

Logs stored in files

› /md/loggd_startup.log

› /md/loggd_persistent.log› /md/loggd_persistent.log1› /md/loggd_persistent.log2› /md/loggd_persistent.log3

Log Messages› /md/loggd_startup.log1

Log Messages

Severity 0,1,2,3

Severity 0,1,2,3,4,5,6


Custom Log fIles and filters[local] Ericsson(config-ctx)# logging file MYLOG.log

[local] Ericsson(config-ctx)# logging filter file ?

alert Log alert and more severe events (priority 1)

critical Log critical and more severe events (priority 2)

debug Log all events, including debug (priority 7)

emergency Log only emergency events (priority 0)

error Log error and more severe events (priority 3)

informational Log informational and more severe events (priority 6)

notice Log notice and more severe events (priority 5)

warning Log warning and more severe events (priority 4)

[local] Ericsson(config-ctx)# logging filter ?

console Configure logging display filter for the console

file Configure logging display filter for file

monitor Configure logging display filter for monitoring terminal

syslog Configure logging display filter for syslog server


Log Files location[local] Ericsson# cd /md

Current directory is now /md

[local] Ericsson# dir

Contents of /md/

total 184484

-rw-r--r-- 1 root root 16 Jun 23 02:23 loggd_ddbg.bin

-rw-r--r-- 1 root root 777848 Jun 23 02:23 loggd_dlog.bin

-rw-r--r-- 1 root root 5081846 Jun 23 06:21 loggd_persistent.log

-rw-r--r-- 1 root root 9751679 Jun 22 22:59 loggd_persistent.log.1



-rw-r--r-- 1 root root 9751660 May 24 21:02 loggd_persistent.log.4

-rw-r--r-- 1 root root 9751711 May 17 02:31 loggd_persistent.log.5

-rw-r--r-- 1 root root 289774 Jun 23 06:20 loggd_startup.log

-rw-r--r-- 1 root root 262601 Jun 23 05:01 loggd_startup.log.1

-rw-rw-r-- 1 root root 16 Aug 22 02:08 MYLOG.log


Display Log Files[local] Ericsson# show log file loggd_dlog.bin

Jun 28 03:08:25.380: %ISP-6-INFO: [isp_heartbeat_register] is called on ACTIVE

Jun 28 03:08:25.393: %PM-3-ERROR: unable to read vx-other from PM

Jun 28 03:08:25.546: %ISSU-6-INFO: [metad/3297] [pid 3297] Unable to get metah table segment (170,2)

errstr: No such file or directory

Jun 28 03:08:26.008: %ISSU-6-INFO: [loggd/1893] Metadata is not avilable for attach

Jun 28 03:08:26.868: %ISSU-6-INFO: [metad/3297] metalib_endian_shm_create:metalib endi

an SHM created OK (0x100045000/0x101c07000)

Jun 28 03:08:26.868: %ISSU-6-INFO: [metad/3297] Can't open file /etc/siara/issu_debug.conf

Jun 28 03:08:26.868: %ISSU-6-INFO: [metad/3297] Failed to parse file /etc/siara/issu_debug.conf

Jun 28 03:08:26.868: %ISSU-6-INFO: [metad/3297] ISSU init ok [metah=1, meta_name=rbos,

m=M, p=rbos_meta.xml.gze:0, c=rbos_meta.xml.gze:6089]

--More--


Filter Based on Facility[local] Ericsson# show log fac ? aaa AAA facility

amcm AMC Manager facility

aos AOS facility

app Application facility

arp ARP facility

asesdk ASESDK facility

asm Remote mini-CSM facility

aspha ASP HA Manager facility

atm ATM facility

bgp BGP facility

bot SSC File Manager facility

--more--

[local] Ericsson# show log file loggd_startup.log fac ? aaa AAA facility

amcm AMC Manager facility

aos AOS facility

app Application facility

arp ARP facility

asesdk ASESDK facility

asm Remote mini-CSM facility

aspha ASP HA Manager facility

…


Filter Based on Facility example[local] Ericsson# show log active fac aaa

Jun 23 05:06:24.312: %AAA-6-INFO: Perform non hitless switchover.

Jun 23 05:06:33.612: %AAA-5-NOTICE: [local] administrator: (test) logged in via tty: /dev/pts/, host: 155.53.235.45




Jun 23 07:07:51.776: %AAA-5-NOTICE: [local] administrator: (test) found on /dev/pts/4 from 155.53.235.45 - record as logged out.




Pm Process Logs

[local] Ericsson# show log active fac pm

Jun 23 21:43:51.474: %PM-6-PROCDIE: rcm is dying, pid 3982

Jun 23 21:43:54.474: %PM-5-GEN: restarting <rcm> now

RCM Process Crash

RPSW Switchover

[local] Ericsson# show log active fac pm

Jun 23 05:06:22.206: %PM-5-GEN: PM received ACTIVE event

Jun 23 05:06:22.206: %PM-5-GEN: Set PM to run in primary mode.

Jun 23 05:06:22.206: %PM-5-GEN: This RP is going Active.

Jun 23 05:06:22.206: %PM-5-GEN: Setting PM as primary.

Jun 23 05:06:22.217: %PM-5-GEN: Reason for controller switch: Card Failed

Jun 23 05:06:22.218: %PM-6-INFO: pm_send_status: Notifying ns

Jun 23 05:06:22.218: %PM-6-INFO: pm_send_status: Notifying rpsw_dtp

pm: process manager


CSM Process Logs[local] Ericsson# show log active fac csm

Jun 23 05:05:15.504: %CSM-6-CARD: card ge-40-port INSERTED in slot 1 READY

Jun 23 05:05:15.505: %CSM-6-CARD: card ge-40-port INSERTED in slot 17 READY

Jun 23 05:05:15.506: %CSM-6-CARD: card alsw INSERTED in slot ALSW1

Jun 23 05:05:15.506: %CSM-6-CARD: card alsw INSERTED in slot ALSW2

Jun 23 05:05:15.506: %CSM-6-CARD: card sw INSERTED in slot SW1





Jun 23 05:05:24.765: %CSM-6-PORT: ethernet 1/12 link state UP service state UP, overall adminis UP

Jun 23 05:05:24.765: %CSM-6-PORT: ethernet 1/14 link state UP service state UP, overall adminis UP

Jun 23 05:05:39.570: %CSM-6-CARD: slot PM5, ALARM_CLEARED: Input Failure - Both Feeds

--More--


ISM Process[local] Ericsson# show log active fac ism

Jun 23 05:05:04.586: %ISM-6-STATE_TOGGLE: This ISM going standby.

Jun 23 05:05:04.607: %ISM-6-CHKPT_OK: Marked ISM checkpoint as OK

Jun 23 05:05:04.796: %ISM-6-PPA_REG1: Switchover is complete and can process PPA registration now.

Jun 23 05:06:22.224: %ISM-6-STATE_TOGGLE: This ISM going active.

Jun 23 05:06:22.226: %ISM-6-SWOVR_TYPE: Performing *** NON HITLESS *** switchover. All dynamic

and subcribers circuits will be deleted.

Jun 23 05:06:22.309: %ISM-6-SENT_IPC: Sent RESYNC ipc to component: CSM.

Jun 23 05:06:24.311: %ISM-6-SENT_EVENT: Sent event: XC RESYNC, to MBE: dot1q

Jun 23 05:06:24.311: %ISM-6-SENT_EVENT: Sent event: XC RESYNC, to MBE: aaa

Jun 23 05:06:24.484: %ISM-6-SENT_EVENT: Sent event: XC DONE, to MBE: aaa

Jun 23 05:06:24.484: %ISM-6-SENT_IPC: Sent XC DONE ipc to component: ifmgr.

Jun 23 05:06:24.484: %ISM-6-SENT_EVENT: Sent event: XC DONE, to client: snmp

Jun 23 05:06:24.485: %ISM-6-PPA_REG1: Switchover is complete and can process PPA registration

now.

Jun 23 05:09:23.292: %ISM-6-SB_RDY_SWOVR: Standby ISM is ready for switchover


filter based on facility on card[local]SSR8020# show log card 3 fac pm

--------------------------------------------------------------

Slot number : 3/LP


Aug 19 16:46:59: {3/LP}: %PM-6-INFO: All run processes initialized

Aug 19 16:47:59: {3/LP}: %PM-6-INFO: Declaring system healthy

[local]SSR8020# show log card 3 fac ns

--------------------------------------------------------------

Slot number : 3/LP


Aug 19 16:46:47: {3/LP}: %NS-6-INFO: New namespace 'RP.ACTIVE' from ep [127.2.253.1:6001|000|003]

Aug 19 16:46:48: {3/LP}: %NS-6-INFO: New namespace 'RP.STANDBY' from ep [127.2.252.1:6001|000|003]

Aug 20 00:39:41: {3/LP}: %NS-6-INFO: New namespace 'LC.05' from ep [127.2.4.1:6001|000|003]


Show Logging information[local] Ericsson# show logging

% Logging Information

% ===================

% Logger Uptime : 05:22:02 Fri Aug 17 2012

% Logger Buffer (KB) : Log: 84, Dbg: 1023

% Logger Buffer Locked : Log: N, Dbg: N

% # Logged msg : Log: 674300, Dbg: 0

% # Logged Filtered : Log: 0, Dbg: 0

% # Logged Rate Limited : Log: 0, Dbg: 0

% ==================

% Logger Drop Counter :

% [ipc] : Log: 50, Dbg: 0

% ==================

%Logger last wrapped at : Log: 05:51:11 Wed Aug 22 2012

% Logger Wrapped : Log: 84, Dbg: 0

% Evnts overwritten : Log: 666358, Dbg: 0


Show Logging Card information[local] Ericsson# show logging card 1

--------------------------------------------------------------

Slot number : 1/LP


% Logging Information

% ===================

% Logger Uptime : 02:10:50 Sat Jun 23 2012

% Logger Buffer (KB) : Log: 979, Dbg: 1023

% Logger Buffer Locked : Log: N, Dbg: N

% # Logged msg : Log: 431, Dbg: 0

% # Logged Filtered : Log: 0, Dbg: 0

% # Logged Rate Limited : Log: 0, Dbg: 0

% ==================

% Logger Drop Counter : All drop counters are all ZERO


Display logging output to screen› When connected to the console port:

– You need to enable logging to the console› [local]Train-1# config› [local]Train-1(config)# context local› [local]Train-1(config-ctx)# logging console

– Logging console is enabled by default only on context local

› When connected via Telnet or SSH:– You need to redirect logging output to your terminal:

› [local]Train-1# terminal Monitor

– To pause logging output:› [local]Train-1# CTRL-S› Press any key to continue

› Only messages up to severity level 5 displayed by default: – Debug level 7 messages displayed only if debug is enabled– Informational level 6 messages not displayed by default

console

telnet / ssh


Logging display info[local]pipd-ssr-81# logging display-info

[local]pipd-ssr-81# terminal monitor

[local]pipd-ssr-81# conf


[local]pipd-ssr-81(config)# port eth 2/8

[local]pipd-ssr-81(config-port)# no shut

[local]pipd-ssr-81(config-port)# commit


Feb 6 15:37:34: %CSM-6-PORT: ethernet 2/8 link state UP service state UP, overall admin is UP

[local]pipd-ssr-81(config-port)#shut

[local]pipd-ssr-81(config-port)#commit

Feb 6 15:38:03: %CSM-6-PORT: ethernet 2/8 link state DOWN service state DOWN, overall admin is DOWN

Feb 6 15:38:03: %CSM-6-PORT: ethernet 2/8 link state down, trigger source: Configuration changed

[local]pipd-ssr-81(config-port)# end

[local]pipd-ssr-81# no logging display-info


[local]pipd-ssr-81(config)# port eth 2/8

[local]pipd-ssr-81(config-port)# no shut

[local]pipd-ssr-81(config-port)# commit

[local]pipd-ssr-81(config-port)#

from release 12.1 level 6 info messages not displayed by default

use of this command is discouraged

For a Line Card:logging card slot display-info


logging debug

› “show log” displays only content of log messages by default

› “logging debug” sends debug message to log buffer

LOG Debug

› /md/loggd_dlog.bin

› /md/loggd_ddbg.bin


Active RPSW

Log engine

Event …..Event …..Event ….

Log file

Debug engine

Term monitor or Logging console

Terminal / console

Log engine

Standby RPSW

Event …..Event …..Event ….

Log file

logging debug (global config logging)

[local]pipd-ssr-81(config)#logging ? active Configure to log active event to standby controller cct-valid Configure to log only event with valid cct debug Configure to log debug events standby Configure to log standby event to active controller timestamp Configure the timestamp information of log[local]pipd-ssr-81(config)#

Logging

activeLogg

ing

stan

dby

Logging debug

Logging debug ONLY sends events which are actually displayed to either console or terminal screen


logging debug[local]pipd-ssr-81# debug static rib

[local]pipd-ssr-81# terminal monitor


[local]pipd-ssr-81(config)# context local

[local]pipd-ssr-81(config-ctx)# ip route 11.12.12.0/24 8.8.8.8

[local]pipd-ssr-81(config-ctx)# commit

Feb 7 15:20:23: %STATIC-7-RIB: register nexthop: 8.8.8.8, context 0x40080001, nexthop_afi 0, metric 4294967295, ifgrid 0x0, default 0, magic 0, bfd-disabled

[local]pipd-ssr-81(config-ctx)# end

[local]pipd-ssr-81# show log | grep "STATIC-7“


[local]pipd-ssr-81(config)# logging debug

[local]pipd-ssr-81(config)# context local

[local]pipd-ssr-81(config-ctx)# ip route 11.12.13.0/24 8.8.8.9

[local]pipd-ssr-81(config-ctx)# commit


[local]pipd-ssr-81(config-ctx)# end

[local]pipd-ssr-81# show log | grep "STATIC-7"


SSR DebuggingSSR Troubleshooting


Debug introduction› Debug – troubleshooting tool

Important facts:› Debug: last resort!› Structured searching› What to debug?

– port, routing ...– System wide debug– Context specific debug

› Where to start debug?– Contexts are autonomous

contextlocal

ABC

XYZ

Resource Intensive!

Last resort!

port

What function to debug?What function to debug?

System wide debug:e.g. debug aaa authen

Context specific debug:e.g. debug ospf lsdb

Which context to start debug from?




Debug relationship with context and function

Debug on SSR

Context specific debug functions can be looked at from two levels:

Debug within a non local context

You only see debug output related to the context

Debug within context local

You will see debug output related to all contexts

System wide debug functions can be looked at from two levels:

Debug within a non local context

You would see all output

Debug within context local

You would see all output

No difference between the two levels….

ContextSSR

System

Non localContext

Contextlocal

Non localContext

Contextlocal


Display debug output to screen

› When connected to the console port:– You need to enable logging to the console

[local]Train-1# config[local]Train-1(config)# context local[local]Train-1(config-ctx)# logging console

– Repeat for each context where debug output needs to be generated

› When connected via Telnet or SSH:– You need to redirect debugging output to your terminal:

[local]Train-1# terminal Monitor

– Repeat for each context where debug output needs to be generated

– To pause debug output:› [local]Train-1# CTRL-S› Press any key to continue

› Debug functions and output unique for each administrator

console

telnet / ssh


Debug commands

› Enabling debug is context specific and requires[local]Train-1# context <context name>[<context name>]Train-1# debug [function]Example:[local]Train-1# context ABC[ABC]Train-1# debug ospf lsdb

› Disabling debug is context specific and requires[local]Train-1# context <context name>[<context name>]Train-1# no debug [function] [<context name>]Train-1# no debug all

› will disable all debug functions in that contextExample:[local]Train-1# context ABC[ABC]Train-1# no debug ospf lsdb

Disconnecting the telnet / SSH session will be handled as implicit “no debug all” for associated administrator


Example debugging within context local

[local]Train-1# show context allContext Name Context ID VPN-RD Description------------------------------------------------------------------------------local 0x40080001Rb-1 0x40080002Rb-2 0x40080003Rb-3 0x40080004Re-1 0x40080005Re-2 0x40080006Re-3 0x40080007[local]Train-1#

[local]Train-1# debug ospf lsdb[local]Train-1# show debugOSPF: lsdb debugging is turned on[local]Train-1# terminal monitor[local]Train-1#Apr 18 12:21:04: %LOG-6-SEC_STANDBY: Apr 18 12:21:04: %CSM-6-PORT: ethernet 3/7 link state UP, admin is UPApr 18 12:21:04: %LOG-6-SEC_STANDBY: Apr 18 12:21:04: %CSM-6-PORT: ethernet 3/8 link state UP, admin is UPApr 18 12:21:05: %CSM-6-PORT: ethernet 3/7 link state UP, admin is UPApr 18 12:21:05: %CSM-6-PORT: ethernet 3/8 link state UP, admin is UPApr 18 12:21:05: [0002]: %OSPF-7-LSDB: OSPF-1: Area 0.0.0.0 Update Router LSA 200.1.1.1/200.1.1.1/80000013 cksum 26f1 len 72Apr 18 12:21:05: [0003]: %OSPF-7-LSDB: OSPF-1: Area 0.0.0.2 Update Router LSA 200.1.2.1/200.1.2.1/80000009 cksum ce79 len 36Apr 18 12:21:05: [0004]: %OSPF-7-LSDB: OSPF-1: Area 0.0.0.3 Update Sum-Net LSA 0.0.0.0/200.1.3.1/80000001 cksum bb74 len 28Apr 18 12:21:05: [0004]: %OSPF-7-LSDB: OSPF-1: Area 0.0.0.3 Update Router LSA 200.1.3.1/200.1.3.1/8000000a cksum 142 len 36Apr 18 12:21:05: [0004]: %OSPF-7-LSDB: OSPF-1: Area 0.0.0.0 Update Router LSA 200.1.1.1/200.1.1.1/80000013 cksum 26f1 len 72Apr 18 12:21:05: [0003]: %OSPF-7-LSDB: OSPF-1: Area 0.0.0.0 Update Router LSA 200.1.1.1/200.1.1.1/80000013 cksum 26f1 len 72Apr 18 12:21:06: [0005]: %OSPF-7-LSDB: OSPF-1: Area 0.0.0.0 Update Router LSA 2.2.2.2/2.2.2.2/8000000a cksum 983b len 36Apr 18 12:21:06: [0006]: %OSPF-7-LSDB: OSPF-1: Area 0.0.0.2 Update Router LSA 2.2.2.6/2.2.2.6/80000009 cksum 7c4e len 36Apr 18 12:21:06: [0007]: %OSPF-7-LSDB: OSPF-1: Area 0.0.0.3 Update Router LSA 2.2.2.10/2.2.2.10/8000000a cksum 803f len 36Apr 18 12:21:06: [0005]: %OSPF-7-LSDB: OSPF-1: Area 0.0.0.0 Update AS-Ext LSA 30.1.1.4/2.2.2.2/80000001 cksum 2821 len 36Apr 18 12:21:06: [0005]: %OSPF-7-LSDB: OSPF-1: Area 0.0.0.0 Update AS-Ext LSA 2.2.2.0/2.2.2.2/80000001 cksum a6c0 len 36Apr 18 12:21:06: [0005]: %OSPF-7-LSDB: OSPF-1: Area 0.0.0.0 Update AS-Ext LSA 30.1.1.0/2.2.2.2/80000001 cksum 50fc len 36---more---

What function?Debug ospf lsdb

Where? context local Capture all


Example outputs from different contexts[NiceService]Train-2# debug aaa author[NiceService]Train-2# show debuggingAAA: authorization debugging is turned on exception debugging is turned on[NiceService]Train-2# terminal monitor

[NiceService]Train-2#Feb 6 15:07:25: [0002]: [13/1:1:63/1/2/11]: %AAA-7-AUTHOR: aaa_idx 1000001e: unprovision attr 13Feb 6 15:07:25: [0002]: [13/1:1:63/1/2/11]: %AAA-7-AUTHOR: aaa_idx 1000001e: aaa_ip_addr_prov: rem pool entry 0x64010117Feb 6 15:07:25: [0002]: [13/1:1:63/1/2/11]: %AAA-7-AUTHOR: aaa_idx 1000001e: unprovision attr 3

[local]Train-2# debug aaa authen[local]Train-2# show debuggingAAA: authentication debugging is turned on exception debugging is turned on[local]Train-2# terminal monitor

[local]Train-2#Feb 6 15:09:13: [13/1:1:63/1/2/11]: %AAA-7-AUTHEN: aaa_idx 1000001f: Received SESSION_DOWN msg extern_handle 0Feb 6 15:09:25: [13/1:1:63/1/2/11]: %AAA-7-AUTHEN: aaa_idx 0: Received AUTHEN_REQUEST msg from PPPd for username user2@NiceService with external handle = 0

What? aaa authorWhere? From context NiceService

only authorization and exception debugging output will be

shown

When looking from within context local only authentication and exception debugging output will be shown

In the examples above, each context has a different debug function enabled. Depending on which context the admin is monitoring from, the debug output will be different.


Show Debugging[local] Ericsson#

AAA:

authentication debugging is turned on

authorization debugging is turned on

accounting debugging is turned on

[local] Ericsson#

[local] Ericsson#

No debugging is turned on.

show debugging

no debug all

show debugging

SSR ConnectivitySSR Troubleshooting


interface & port states

Line Admin

Down Down

Down Up

Interfaces and ports different entities on SSR Distinct states

Port state not affected by interface state

Three states for a portThree states for an interface

Unbound Bound

local

Context

1/1VLAN

Interface

Port

Port/circuit

Up Down Up

Line Admin

Up Up

Bound-interface state determined by port state

Binding Interface

Configured Port States

Bound -Interfaces States

Unconfigured


[test]SR1-1#

Sun Jun 24 21:57:07 2012

Name Address MTU State Bindings

loopback 1.1.1.1/32 1500 Up (Loopback)

test1 4.4.4.2/30 0 UnBound

test2 5.5.5.2/30 1500 Bound dot1q 3/10 vlan-id 10

[test]SR1-1# show port 3/10

Slot/Port:Ch:SubCh:SubSubCh Type State

3/10 ethernet Down

Interface StatesThree possible states for an interface:

Unbound: interface not bound to any circuit or port

Bound: interface bound to a circuit or port but bound circuit or port is not up

Up: interface bound to a circuit or port and bound circuit or port is up

show ip interface brief

Loopback always Up

Not Bound to any port

SHOW IP INTERFACE

Bound to a port in down state

Port State is Down


[test]SR1-1#

Sun Jun 24 21:57:07 2012




[test]SR1-1#

[test]SR1-1#

[test]SR1-1# show binding bound | grep test1

[test]SR1-1#

Interface State - Unboundshow ip interface brief

show conf port | grep test1

Context

local

1/1VLAN

Interface

Port/CIRCUIT

No Binding


Interface State - UnboundUnbound

conf[test]SR1-1#


[test]SR1-1(config)#

[test]SR1-1(config-port)#




Sun Jun 24 21:57:57 2012



test1 4.4.4.2/30 1500 Up ethernet 3/5[test]SR1-1(config-port)# show port 3/5Slot/Port:Ch:SubCh:SubSubCh Type State3/5 ethernet Up

sh ip int brief

port ethernet 3/5

bind interface test1 test

commit

Up

Bound

local

1/1VLAN

Interface

Port/CIRCUIT

Context



[test]SR1-1(config-port)#dot1q pvc 10

[test]SR1-1(config-dot1q-pvc)#bind interface test2 test

[test]SR1-1(config-dot1q-pvc)#commit


[test]SR1-1(config-dot1q-pvc)# end

[test]SR1-1#

Sun Jun 24 22:16:29 2012



test1 4.4.4.2/30 1500 Up ethernet 1/11

test2 5.5.5.2/30 1500 Bound dot1q 3/10 vlan-id 10

[test]SR1-1#


3/10 ethernet Down

Interface State - BOUND Layer 1 or 2 problem ?Bound

port ethernet 3/10

sh ip int brief

show port 3/10

local

1/1VLAN

Interface

Port/CIRCUIT

Context

Bound


[test]SR1-1(config-port)# show port all


…

3/1 ethernet Unconfigured

3/2 ethernet Down

3/3 ethernet Up

…

[test]SR1-1(config)# no port eth 3/1

[test]SR1-1(config)#commit


[test]SR1-1(config)# port eth 3/1

port States

Three possible states for a port:Unconfigured: port is not configured

Down: port is configured but in down state

Up: port is configured and in up state

Line Admin

Down Down

Down Up

Up Up


Why is the Port Down?

Line Admin Port

Down Up Down

[test]SR1-1#

ethernet 3/11 state is Down

Description :

Port circuit : 3/11:511:63:31/1/0/32

Link state : Down

Last link state change : Aug 5 17:45:20.616

Line state : Down

Admin state : Up

Link Dampening : disabled

Undampened line state : Down

…

[test]SR1-1(config)# port ethernet 3/11

[test]SR1-1(config-port)# no shutdown


show port 3/11 detail

Administratively configured and enabled but not operating


Why is the Port Down 2?

Line Admin Port

Down Down Down

[test]SR1-1#

ethernet 3/10 state is Down

Description :

Port circuit : 3/10:511:63:31/1/0/30

Link state : Down


Line state : Down

Admin state : Down


Undampened line state : Down

Dampening Count : 0

Encapsulation : dot1q

MTU size : 1500 Bytes

NAS-Port-Type : none

NAS-Port-Id : none

MAC address : 00:02:3b:04:65:6f

--More--

sh port 3/10 detail

Not Administratively enabled

Line: Up, Admin: Down combination not possible


FIXING Port Down 2

Line Admin Port

Up Up Up

[local]SR1-1(config)#

[local]SR1-1(config-port)#no shutdown

[local]SR1-1(config-port)#commit


[local]SR1-1(config-port)#

ethernet 3/10 state is Up

Description :

Port circuit : 3/10:511:63:31/1/0/30

Link state : Up


Line state : Up

Admin state : Up


Undampened line state : Up

--More--

port ethernet 3/10

show port 3/10 detail


BoundBound

[local]SR1-1(config-port)#

Sat Aug 11 05:41:22 2012




test2 5.5.5.2/30 1500 Up dot1q 3/10 vlan-id 10


Up

show ip int brief


Circuit StatesUsually same state as port

Keep-alives may cause circuit to go down without Port state going down e.g. PPPoE

Circuits may be administratively shut down while port remains up


[local]Ericsson(config-port)# dot1q pvc 100

[local]Ericsson(config-dot1q-pvc)# shutdown

[local]Ericsson#

Circuit Internal Id Encap State Bound to

1/11 vlan-id 102 1/2/176090 dot1q Up inter_router@local

1/11 vlan-id 100 1/2/184280 dot1q Down test1@test

port ethernet 1/11

sh circuit dot1q


Traffic problemsSimple Checks may not resolve Connectivity Problems.

local

Context

1/1VLAN

InterfacePort/Circuit

?

SSR Counters

[local]Ericsson#

Port Type

1/3 ethernet






show port counters 1/3

Packets Bytes

Refreshed every few minutes


Live Counters

[local]Ericsson#

Port Type

1/11 ethernet






show port counters 1/3 live

Updates displayed when command executed

Still refreshed every 60 seconds


Show port counters detail• NPU Port Counters

• NPU Input Error Counters

• NPU Output Error Counters

• Packet Drop Counters

• Policing Counters

• General Counters

• Transmit Counters

• Receive Counters

NP4

SF

P

FAP

SF

PS

FP

SF

PS

FP

GbE PHY

STATS MEM

TMMEM

SRCH MEM

ACLMEM

STATSMEM

BUFFER

CONTROLCPU

RTC

PLL FPGA

SSR Line Card

ErrorsErrors

Packet Drop


Circuit Counters

[local]Ericsson#

Circuit Packets/Bytes Sent Packets/Bytes Received

1/11 vlan-id 102 33992 33864

2929662 2927535

1/12 vlan-id 22 597298455 896004199

472372041108 708657546458

1/14 vlan-id 410 298957808 307076082

235053635771 241668145938

1/14 vlan-id 810 298647205 307076064

235023077548 241668183541

[local]Ericsson#

Circuit Packets/Bytes Sent Packets/Bytes Received

3/7 vlan-id 101 69879 69867

6026610 6014418

show circuit counters

show circuit counters 3/7 vlan-id 101


Circuit Counters detailed[local]Ericsson#

Circuit: 1/14 vlan-id 410, Internal id: 1/2/12289, Encap: ether-dot1q

Packets Bytes

-------------------------------------------------------------------------------

Receive : 307496939 Receive : 241999367703

Receive/Second : 3950.50 Receive/Second : 3110374.20

Transmit : 299378699 Transmit : 235384868904

Xmits/Queue Xmits/Queue

0 : 299378699 0 : 235384868904

1 : 0 1 : 0

2 : 0 2 : 0

3 : 0 3 : 0

4 : 0 4 : 0

5 : 0 5 : 0

6 : 0 6 : 0

--More--

show circuit counters 1/14 vlan 410 detail

Transmit

Receive

Queues

Multicast

Drops

MPLS

ARP

..and more


Clear Counters

[local]Ericsson#

[local]Ericsson#

[local]Ericsson#

Port Type

1/3 ethernet






--More—

[local]Ericsson#

[local]Ericsson#

[local]Ericsson#

clear circuit counters

clear port counters

sh port counters

Counters reset to 0

clear circuit counters 3/10 vlan-id 100

clear port counters 3/5

Documents

SSR Knowleadge Sharing all-in-one.pptx