Технический тренинг

ACX, MX Juniper Networks

История инноваций Juniper
• 1998: First separation of control plane & data plane
• 1998: First implementation of IPv4, v6, MPLS in silicon
• 1998: First 2.4Gbps forwarding engine
• 2000: First wire-rate 10Gbps forwarding engine
• 2002: First implementation of integrated services
• 2003: First scalable cell-switched fabric
• 2004: First multi-chassis router
• 2005: First line-rate 40Gbps forwarding engine
• 2007: First Ethernet router
• 2007: First > 160G Firewall
• 1998-2006: Record quadrupling of capacity every 2 years
• 2009: Next generation edge silicon: NISP
• 2010: First 100GE

За 11 лет - 78 микросхем собственной разработки!

ТИПИЧНЫЕ СЦЕНАРИИ
ПРИМЕНЕНИЯ
MOBILE BACKHAUL – REFERENCE MODEL(1)
Inter-Region Service Plane

Inter-Region Transport LSP Inter-Region Transport LSP Inter-Region Transport LSP

Local IGP Local IGP Local IGP

Local Transport LSP Local Transport LSP Local Transport LSP

PE1 P1 ASBR1 ASBR2 P2 ASBR3 ASBR4 P3 PE2

Edge Region - 1 Transport Region Edge Region - 2

- Multiple Autonomous Systems

MOBILE BACKHAUL – REFERENCE MODEL(2)
Inter-Region Service Plane

Inter-Region Transport LSP Inter-Region Transport LSP Inter-Region Transport LSP

Local IGP Local IGP Local IGP

Local Transport LSP Local Transport LSP Local Transport LSP

PE1 P1 ABR1 P2 ABR2 P3 PE2

Edge Region - 1 Transport Region Edge Region - 2

- Single Autonomous System – Multiple Areas/Levels

SEAMLESS MPLS ARCHITECTURE 1588v2 GM
Pre-Agg
CSR

Core

Agg
Access Pre-Aggregation

Service Node

AS 65001 AS 65002

ISIS level 1 with BFD ISIS level 2 with BFD Physically connected ISIS level 2 with BFD

RSVP with BFD RSVP with BFD Physically connected RSVP with BFD

LDP DoD over RSVP 3107 I-BGP with BFD 3107 E-BGP with BFD 3107 I-BGP with BFD

Any Service Any Service

Any Service Any Service

Any Service

6
SEAMLESS MPLS ARCHITECTURE 1588v2 GM
Pre-Agg
CSR

Core

Agg
Access Pre-Aggregation

Service Node

AS 65001 AS 65002

ISIS level 1 with BFD ISIS level 2 with BFD Physically connected ISIS level 2 with BFD

RSVP with BFD RSVP with BFD Physically connected RSVP with BFD

LDP DoD over RSVP 3107 I-BGP with BFD 3107 E-BGP with BFD 3107 I-BGP with BFD

Any Service Any Service

Any Service Any Service

Any Service

7
SEAMLESS MPLS ARCHITECTURE
SOLUTION OPTIONS
•1) End to End L3 MPLS VPN
•2) Pseudo wire in Access & L3 MPLS VPN in Agg/Core
•3) Pseudo wire in Access & VPLS in Agg/Core
•4) TDM/ATM PWs
1) L3VPN END-TO-END TOPOLOGY 1588v2 GM L3VPN Instance with
Pre-Agg vrf-table-label. All CSRs and Pre-
CSR Agg routers have the L3VPN
instance

All RSVP will have primary and

secondary paths with fast
reroute

Agg routers are RRs for Pre-aggs

Core Pre-agg routers are RRs for CSRs

Agg
Access Pre-Aggregation

Service Node

AS 65001 AS 65002

ISIS level 1 with BFD ISIS level 2 with BFD Physically connected ISIS level 2 with BFD

RSVP with BFD RSVP with BFD Physically connected RSVP with BFD

3107 I-BGP with BFD 3107 E-BGP with BFD 3107 I-BGP with BFD

MP-IBGP (VPNv4) MP-EBGP (VPNv4)

All VPNv4 prefixes All VPNv4 prefixes

Aggregate/default route only Aggregate/default route only

9
1) L3VPN END-TO-END TOPOLOGY
IGP DESIGN - ACCESS
1588v2 GM L3VPN Instance with
Pre-Agg vrf-table-label. All CSRs and Pre-
CSR  Level-1 ISIS area. Agg routers have the L3VPN
instance

All RSVP will have primary and

 BFD at 10ms for ISIS fast convergence.secondary paths with fast
reroute

Agg routers are RRs for Pre-aggs

 5 to 7 routers in a ring. (typically
Core example)
Pre-agg routers are RRs for CSRs

 Each pair of AG1Aggrouters can terminate

Access Pre-Aggregation
multiple rings.
- 30 nodes to 200 nodes per Pre-Agg pair.
Service Node
 Each ISIS area with up to 200 routers.
 No route-leaking, unless specific reasons,
between Access and Pre-Agg rings.
1) L3VPN END-TO-END TOPOLOGY
LSP DESIGN - ACCESS
1588v2 GM L3VPN Instance with
Pre-Agg vrf-table-label. All CSRs and Pre-
CSR  RSVP based LSPs from each CSR. Agg routers have the L3VPN
instance

All RSVP will have primary and

 LSPs from CSR to a pair of AG1s secondary paths with fast
reroute

[Pre-Agg Nodes]. Core

Agg routers are RRs for Pre-aggs
Pre-agg routers are RRs for CSRs

 FRR/LP/NLP based protection.

Agg
Access Pre-Aggregation
 Secondary LSP paths if needed.
 Full mesh of LSPs if needed. Service Node

11
1) L3VPN END-TO-END TOPOLOGY
IGP DESIGN - AGGREGATION
1588v2 GM L3VPN Instance with
Pre-Agg vrf-table-label. All CSRs and Pre-
CSR Agg routers have the L3VPN
instance

All RSVP will have primary and

secondary paths with fast
reroute

Agg routers are RRs for Pre-aggs

Core Pre-agg routers are RRs for CSRs

Agg
Access Pre-Aggregation

Service Node

 Level-2 ISIS area.

 BFD at 10ms for ISIS fast convergence.
 Each pair of AG2 routers can terminate
multiple rings.
 No route-leaking between Access and Pre-Agg rings.

12
1) L3VPN END-TO-END TOPOLOGY
LSP DESIGN - AGGREGATION
1588v2 GM L3VPN Instance with
Pre-Agg vrf-table-label. All CSRs and Pre-
CSR Agg routers have the L3VPN
instance

All RSVP will have primary and

secondary paths with fast
reroute

Agg routers are RRs for Pre-aggs

Core Pre-agg routers are RRs for CSRs

Agg
Access Pre-Aggregation

Service Node

 RSVP based LSPs.

 LSPs from AG1s and AG2 pair.
 FRR/LP/NLP based protection.
 Secondary LSP paths if needed.

13
1) L3VPN END-TO-END TOPOLOGY
IGP AND LSP SUMMARY 1588v2 GM L3VPN Instance with
Pre-Agg vrf-table-label. All CSRs and Pre-
CSR Agg routers have the L3VPN
instance

All RSVP will have primary and

secondary paths with fast
reroute

Agg routers are RRs for Pre-aggs

Core Pre-agg routers are RRs for CSRs

Agg
Access Pre-Aggregation

Service Node

AS 65001 AS 65002

ISIS level 1 with BFD ISIS level 2 with BFD Physically connected ISIS level 2 with BFD

RSVP with BFD RSVP with BFD Physically connected RSVP with BFD

14
1) L3VPN END-TO-END TOPOLOGY
BGP DESIGN SUMMARY
1588v2 GM L3VPN Instance with
Pre-Agg vrf-table-label. All CSRs and Pre-
CSR Agg routers have the L3VPN
instance

All RSVP will have primary and

secondary paths with fast
reroute

Agg routers are RRs for Pre-aggs

Core Pre-agg routers are RRs for CSRs

Agg
Access Pre-Aggregation

Service Node

3107 I-BGP with BFD 3107 E-BGP with BFD 3107 I-BGP with BFD

MP-IBGP (VPNv4) MP-EBGP (VPNv4)

All VPNv4 prefixes All VPNv4 prefixes

Aggregate/default route only Aggregate/default route only

15
 1) L3VPN END-TO-END TOPOLOGY
TRAFFIC FLOW FROM CSR TO EPC (A->B)
1588v2 GM L3VPN Instance with
Pre-Agg vrf-table-label. All CSRs and Pre-
CSR Agg routers have the L3VPN
instance

All RSVP will have primary and

secondary paths with fast
reroute

Agg routers are RRs for Pre-aggs

Core Pre-agg routers are RRs for CSRs

Agg
Access Pre-Aggregation
push 4444,2222,100 swap 2222->1111
push 99,10
pop 1111
A
vrf ip look up B
swap 10->20
BGP-L : 1111 Service Node
pop 20 pop 200
swap 100->200

VC-L : 4444
VC-L : 99
AS 65001 AS 65002

ISIS level 1 with BFD ISIS level 2 with BFD Physically connected ISIS level 2 with BFD

RSVP with BFD RSVP with BFD Physically connected RSVP with BFD

3107 I-BGP with BFD 3107 E-BGP with BFD 3107 I-BGP with BFD

MP-IBGP (VPNv4) MP-EBGP (VPNv4)

All VPNv4 prefixes All VPNv4 prefixes

Aggregate/default route only Aggregate/default route only

16
 1) L3VPN END-TO-END TOPOLOGY
TRAFFIC FLOW FROM CSR TO EPC (B->A)
1588v2 GM L3VPN Instance with
Pre-Agg vrf-table-label. All CSRs and Pre-
CSR Agg routers have the L3VPN
instance

All RSVP will have primary and

secondary paths with fast
reroute

VC-L : 8888 Agg routers are RRs for Pre-aggs

VC-L : 88 Core Pre-agg routers are RRs for CSRs
BGP-L : 7777

Agg
Access Pre-Aggregation
swap 5555->100
push 88,100
swap 7777->5555
A
vrf ip look up B
pop 200 push 8888,7777Service
BGP-L : 3333 Node
swap 100->200
swap 100->200
pop 200 BGP-L : 5555

AS 65001 AS 65002

ISIS level 1 with BFD ISIS level 2 with BFD Physically connected ISIS level 2 with BFD

RSVP with BFD RSVP with BFD Physically connected RSVP with BFD

3107 I-BGP with BFD 3107 E-BGP with BFD 3107 I-BGP with BFD

MP-IBGP (VPNv4) MP-EBGP (VPNv4)

All VPNv4 prefixes All VPNv4 prefixes

Aggregate/default route only Aggregate/default route only

17
 1) L3VPN END-TO-END TOPOLOGY
END-TO-END TRAFFIC FLOW
1588v2 GM L3VPN Instance with
Pre-Agg vrf-table-label. All CSRs and Pre-
CSR Agg routers have the L3VPN
instance

All RSVP will have primary and

secondary paths with fast
reroute
S1
Agg routers are RRs for Pre-aggs
Core Pre-agg routers are RRs for CSRs

Agg
Access

A X2 B
Service Node

AS 65001 AS 65002

ISIS level 1 with BFD ISIS level 2 with BFD Physically connected ISIS level 2 with BFD

RSVP with BFD RSVP with BFD Physically connected RSVP with BFD

3107 I-BGP with BFD 3107 E-BGP with BFD 3107 I-BGP with BFD

MP-IBGP (VPNv4) MP-EBGP (VPNv4)

All VPNv4 prefixes All VPNv4 prefixes

Aggregate/default route only Aggregate/default route only

18
 1) L3VPN END-TO-END TOPOLOGY
TRAFFIC FLOW IN THE ACCESS
1588v2 GM L3VPN Instance with

CSR
S1:
Pre-Agg vrf-table-label. All CSRs and Pre-
Agg routers have the L3VPN
instance
Several VRFs may be used (S1-U, S1-MME) All RSVP will have primary and
secondary paths with fast
reroute
AppliesS1also to S1-Flex Agg routers are RRs for Pre-aggs
Core Pre-agg routers are RRs for CSRs

Dedicated VRFs:
Agg
Access
Other VRFs can be provisioned for Management,


A X2 billing, wholesale, Business VPNs, etc B

Service Node
X2 X2:
In the X2 case, any to any can be achieved:
AS 65001
RSVP full mesh (auto-mesh) AS 65002

ISIS level 1 with BFD iBGP full mesh

ISIS level 2 with BFD Physically connected ISIS level 2 with BFD

RSVP with BFD RSVP with BFD Physically connected RSVP with BFD
Or any partial mesh
3107 I-BGP with BFD 3107 E-BGP with BFD 3107 I-BGP with BFD

MP-IBGP (VPNv4)
At the expense of additional provisioning
MP-EBGP (VPNv4)

All VPNv4 prefixes X2 over 2 access rings

 stillprefixes
All VPNv4 go through the pre-
Aggregate/default route only Aggregation nodeAggregate/default route only
19
 L2ckt. All CSRs will originate
L2ckts

L3VPN Instance with

2) L2CKT + L3VPN TOPOLOGY vrf-table-label. All Pre-Agg

routers have the L3VPN
instance. L2CKT terminates into
L3VPN using LT interfaces.

1588v2 GM All RSVP will have primary and

Pre-Agg secondary paths with fast
CSR reroute

Agg routers are RRs for Pre-

aggs
Phase 1: L2Ckt is in backup mode
(non-hot standby)
Phase 2: L2Ckt is in hot-standby
redundancy mode using Status
Core TLV

Agg
Access Pre-Aggregation

Service Node

AS 65001 AS 65002

ISIS level 1 with BFD ISIS level 2 with BFD Physically connected ISIS level 2 with BFD

RSVP with BFD RSVP with BFD Physically connected RSVP with BFD

3107 I-BGP with BFD 3107 E-BGP with BFD 3107 I-BGP with BFD
L2Ckt with PW redundancy MP-EBGP (VPNv4)

All VPNv4 prefixes

Stub Network
Aggregate/default route only
 L2ckt. All CSRs will originate
L2ckts

VPLS Instance . All Pre-Agg

3) L2CKT-VPLS END-TO-END TOPOLOGY routers have the VPLS instance.

L2CKT terminates into VPLS using
virtual switch.

1588v2 GM All RSVP will have primary and

Pre-Agg secondary paths with fast
CSR reroute
Agg routers are RRs for Pre-aggs

Phase 1: L2Ckt is in backup mode

(non-hot standby)
Phase 2: L2Ckt is in hot-standby
redundancy mode using Status
Core TLV

Agg
Access Pre-Aggregation

Service Node

AS 65001 AS 65002

ISIS level 1 with BFD ISIS level 2 with BFD Physically connected ISIS level 2 with BFD

RSVP with BFD RSVP with BFD Physically connected RSVP with BFD

3107 I-BGP with BFD 3107 E-BGP with BFD 3107 I-BGP with BFD
L2Ckt with PW redundancy VPLS
4) TDM AND ATM – SINGLE HOMED
1588v2 GM Service end points
Pre-Agg
CSR
ATM : IMA on CSR and STM-1 or
GE on Service Node
TDM: SATOP or CESOP

Core

Agg
Access Pre-Aggregation

Service Node

AS 65001 AS 65002

ISIS level 1 with BFD ISIS level 2 with BFD Physically connected ISIS level 2 with BFD

RSVP with BFD RSVP with BFD Physically connected RSVP with BFD

LDP DoD over RSVP 3107 I-BGP with BFD 3107 E-BGP with BFD 3107 I-BGP with BFD

SATOP, CESOP and ATM PWs with PW redundancy (Intra/Inter Chassis APS)

The above topology is not typical for TDM/ATM termination in MBH. They are usually terminated on or closer to Agg-routers. In that case,
the design would be much simpler, but would still fall under the same boarder Seamless-MPLS design.
4) TDM AND ATM – DUAL HOMED
1588v2 GM Service end points
Pre-Agg
CSR
ATM : IMA on CSR and STM-1 or
GE on Service Node
TDM: SATOP or CESOP

Agg
Access Pre-Aggregation

Service Node

AS 65001

ISIS level 1 with BFD ISIS level 2 with BFD

RSVP with BFD RSVP with BFD

LDP DoD over RSVP 3107 I-BGP with BFD

SATOP, CESOP and ATM PWs with PW redundancy (Intra/Inter Chassis APS)

The above topology is not typical for TDM/ATM termination in MBH. They are usually terminated on or closer to Agg-routers. In that case,
the design would be much simpler, and would still fall under the same boarder Seamless-MPLS design.
Операционная система JUNOS
 Находится в эксплуатации
с 1998
 Изначально была
спроектирована с учётом
требований операторов
связи
 Модульный подход
• Защита от сбоев
• Перезапуск
• Разделение процессов
• Защита памяти
Программная архитектура JUNOS
Несколько полезных функций
• Commit
• Иерархия команд
• OP-скрипты
 COMMIT: применение конфигурации
1 2 3
commit
load candidate validated active

rollback
configuration configuration configuration
commit
confirmed commit commit 1
scripts validations 49
• Разделение процесса: редактирование и непосредственно применение
• Преимущества
– Ошибки конфигурации можно избежать
– Уменьшается время на внесение изменений
– Можно запрограммировать политики конфигурации
– Avoid risks of transient configuration state
– Можно сравнивать различные версии
– Возможен откат к предыдущим версиям
Иерархическая структура команд
• Логические структуры разделяют конфигурацию
– Глубокие уровни более специфичны
– Возможно создание пользовательских шаблонов
– Конфигурационные группы уменьшают трудозатраты
• Существенное удобство работы с конфигурацией
Top level
node

2nd level
nodes ... ... ...
3rd level
nodes ... ... ... ...
... ... ... ...
... ... ... ...
Автоматизация повседневных задач
 Возможно создание
специальных
скриптов под
специфичные Op Actions
нужды Command-Line Scripts
Execution
 Возможно
объединение lab@SaoPaulo> op terse-int customer ACME   
нескольких команд Interface      Admin Link Proto    Local        Remote
в один скрипт so-0/1/2        up    up 
so-0/1/2.501    up    up   inet   172.31.31.1/30 
Автоматизация событий
События вызывают выполнение определенных скриптов.
 Возможна корреляция
событий и сбор
информации Событие Действия
Event
 На каждое событие можно Scripts
задать предопределенные
действия
Автоматизация конфигураций
COMMIT
   
CANDIDATE ACTIVE
Configuration Configuration

 Abstract complex
configuration into a Benefits
simple set of base Assure compliance to
commands business rules and policies
 Enforce best Actions Provide change
practices and management to avert and
business rules correct errors
Commit Simplify and speed setup
Scripts
of complex configuration
Основные операции при обновлении и
установке OS (1)
По мере того как появляются новые возможности или решаются проблемы с
существующим софтом, возможно периодическое обновление Junos OS.

Перед обновлением Junos OS лучше подстраховаться:

user@host> request system snapshot
Для обновления Junos OS необходимо:
 скопировать Junos OS на маршрутизатор
 добавить новое ПО
 запустить новое ПО

Копирование Junos OS:

Чтобы скопировать Junos OS на маршрутизатор необходимо выполнить команду:
user@host> file copy ftp://username: [email protected]. net/jinstall-package-
name/var/tmp/jinstall-package-name
Основные операции при обновлении и
установке OS (2)
Добавление нового ПО:
user@host> request system software add /var/tmp/jinstall-package—name
Перед тем как новое ПО будет установлено, существующее автоматически удаляется.
Пример.
user@host> request system software add /var/tmp/jinstall-5.2R2.3-domestic.tgz
Installing package '/var/tmp/jinstall-5.2R2.3-domestic.tgz
Auto-deleting old jroute...
Auto-deleting old jdocs...
Auto-deleting old jpfe...
Auto-deleting old jkernel...
Adding JUNOS base software 5.2R2.3
Adding jkernel...
Adding jpfe...
Adding jdocs...
Adding jroute...
NOTICE: uncommitted changes have been saved in /var/db/config/juniper.conf.pre-install
Saving package file in /var/sw/pkg/jinstall-5.2R2.3-domestic.tgz
Основные операции при обновлении и
установке OS (3)
Несмотря на то, что новое ПО установлено, изменения не вступят в силу, пока
маршрутизатор не будет перезагружен.
Запуск нового ПО:
Перегружаем маршрутизатор
user@host> request system reboot

Back Up нового ПО:

user@host> request system snapshot
Порядок загрузки маршрутизатора MX-серии
The M Series, MX Series (except for the MX80 routers) routers attempt to
boot from the storage media in the following order:
1. Removable media
2. CompactFlash card (if present)
3. Hard disk

MX80 routers attempt to boot from the storage media in the following order:
4. USB media
5. Dual, internal NAND flash device (first da0, then da1)

Note: Do not insert the removable media during normal operations. The
router does not operate normally when it is booted from the removable
media.
Пользовательский доступ
• Существует понятие класса пользователя
• Пользователь remote – специальный
пользователь для удаленных подключений
• Пользователю можно задавать ограничения для
выполнения конфигурационных команд
• При ограничениях используются классы и
регулярные выражения
Пример создания пользователя в радиус
The Junos OS uses one or more template accounts to perform user authentication. You create the template
account or accounts, and then configure the user access to use that account. If the RADIUS server is
unavailable, the fallback is for the login process to use the local account that set up on the router or switch.
The following example shows how to configure RADIUS authentication:
Просмотр процессов
lab@mx80> show system processes extensive
last pid: 63918; load averages: 0.14, 0.31, 0.36 up 12+22:07:53 09:50:25
144 processes: 5 running, 111 sleeping, 28 waiting

Mem: 587M Active, 80M Inact, 204M Wired, 328M Cache, 112M Buf, 789M Free
Swap: 2915M Total, 2915M Free

PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND
11 root 1 171 52 0K 16K RUN 283.1H 91.16% idle
1168 root 10 8 0 9328K 3988K RUN 21.9H 5.03% clksyncd
12 root 1 -20 -139 0K 16K WAIT 95:31 0.00% swi7: clock
1153 root 1 96 0 28656K 9200K select 22:00 0.00% chassisd
1220 root 3 20 0 80256K 36764K sigwai 15:13 0.00% jpppd
1174 root 1 96 0 6940K 1836K select 13:34 0.00% license-check
1197 root 1 96 0 13620K 7032K select 9:41 0.00% l2ald
63323 lab 1 96 0 24160K 15540K select 8:50 0.00% cli

Или….
Router-cli> start shell
%top
Конфигурация процессов
• Единственные свойства процессов, на которые можно
воздействовать: генерировать или нет core-файл, отключить
или нет процесс
• Иерархия [edit system processes] позволяет включать эти опции
• Команда show system core-dumps показывает core-файлы
процессов

lab@mx80> show system core-dumps

/var/crash/*core*: No such file or directory
/var/tmp/*core*: No such file or directory
/var/tmp/pics/*core*: No such file or directory
/var/crash/kernel.*: No such file or directory
/tftpboot/corefiles/*core*: No such file or directory
Лабораторная работа
• Каждый маршрутизатор R<N> имеет адрес 172.16.1.(30+N)
• Протокол доступа: SSH
• Пользователь: lab . Пароль: lab123.
• Проверьте доступность адреса 192.168.207.1 с маршрутизатора,
используя утилиту ping
• Воспользуйтесь опцией комментариев при внесении конфигурации и
создайте «пустой» коммит с описание “initial lab configuration”
• Создайте дополнительный адрес на lo интерфейса (например,
172.16.2.N/32) и проверьте конигурацию с использованием опции “check”.

• Используйте опцию confirmed через 2 минуты для возврата

конфигурации в исходное состояние для предыдущего пункта
• Просмотрите версии всех демонов, используемых маршрутизатором, с
помощью команды “show version” и опций к ней
• Введите команду “show version and-haiku” несколько раз 
JUNOS - релизы
• 3 релиза в год
• Патчи для каждого релиза – набор критических исправлений в
рамках релиза, которые в большинстве случаев не требует остановки
в работе сервиса
• 1 релиз в год с расширенной поддержкой – патчи для него делают в
течение 3 лет
• Рекомендуется ставить релиз с расширенным End of Life и последним
патчем
• Существуют специальные сервисные релизы – в них аккумулируются
всевозможные обновления кода для исправления существующих
багов
Маршрутизаторы МХ
Серия MX
Сервисный маршрутизатор MX
– Поддерживает функции коммутации
на втором уровне и маршрутизации
на третьем уровне
– Полнофункциональный маршрутизатор,
проверенная временем операционная система
JUNOS и передовые возможности IPv4/IPv6/MPLS
– Высокая плотность интерфейсов 10GE и GE,
средства манипуляции Ethernet-кадрами
– Высокая доступность
– Функции PE для L3VPN, L2VPN, VPLS, internet
Как выглядит линейка МХ сегодня

2,64 Тбит/с Juniper MX960

1,44 Тбит/с

480 Гбит/с Juniper MX480

Juniper MХ240
80 Гбит/с

Juniper MX80
 MX: Характеристики

MX80 MX240 MX480 MX960

Всего портов 10GE 8 32 96 176

10GE на скорости 6-8 24 72 132

канала
Высота, RU 2 5 8 16

Энергопотребление
(теоретический 500 1420 2880 5093
максимум), Вт, DC-
питание
 Платформа MX960
 Шасси с 14-ю отсеками
 Размеры
– Высота: 16RU (около 1/3 стойки), глубина:<800 мм
 Надёжная аппаратура
– Пассивная Mid-Plane
– Резервируемые модули управления
– Резервируемые модули коммутации (2+1)
– Распределённая подсистема коммутации
– Резервирование подсистемы охлаждения и электропитания
 Электропитание и охлаждение
– Вентиляция в направлении с лицевой стороны на обратную
сторону
– Два отсека вентиляции (резервирование 1+1)
– До 4-х блоков питания (2+2 DC, 3+1 AC)
– Rear-side power cabling
 Ёмкость
– 14 слотов - 2 для матрицы коммутации/модулей управления с
возможностью установки дополнительной матрицы
коммутации
– До 1,3Тбит/с (полный дуплекс) с 11 картами (до 120Гбит/с на
слот)
Компоненты MX960
Switch
SCB -
l Board
Contro
Control tin g
RE- Rou
Panel Engin e

Upper
Fantray
MPC
SCB

RE

Lower Cable
Fantray Mgmnt
Air
Intake
МХ 960 - back
Охлаждение

Блоки питания

Заземление
 Платформа MX480
 Шасси с 8-ю отсеками
 Размеры • Общая с MX960 аппаратная база
– Высота: 8RU (около 1/6 стойки), – Единый комплекс RE/SCB
глубина:<800 мм – Одинаковые DPC
• Общее ПО JunOS
 Надёжная аппаратура
• Варианты комплектации RE
– Пассивная Mid-Plane – 1.3GHz процессор с 2GB
– Резервируемые модули управления – 2 GHz процессор с 4GB
– Резервируемые модули коммутации (1+1)
– Распределённая подсистема коммутации
– Резервирование подсистемы охлаждения и
электропитания
 Электропитание и охлаждение
– Вентиляция в направлении от боковой стенки к
боковой стенке
– Резервирование вентиляторов
– До 4-х блоков питания (2+2 DC, 2+2 AC)
– Общее энергопотребление ~2800Вт
 Ёмкость
– 8 слотов - 2 для матрицы коммутации/модулей
управления
– До 720Гбит/с (полный дуплекс) с 6 карт
Платформа MX240
• Шасси с 4-мя отсеками (2+2 or 3+1) • Общая с MX960 аппаратная база
• Размеры • Единый комплекс RE/SCB
– Высота: 5RU, Глубина: <800 мм • Одинаковые DPC
• Надежная аппаратура
– Пассивная Mid-Plane • Общее ПО JunOS
– Резервируемые модули управления • Варианты комплектации RE
(в конфигурации 2+2) • 1.3GHz процессор с 2GB
– Резервируемые модули коммутации (1+1)
– Распределённая подсистема коммутации • 2 GHz процессор с 4GB
– Резервирование подсистемы охлаждения и
электропитания
• Электропитание и охлаждение
– Вентиляция по направлению от боковой стенки к
боковой стенке
– Резервирование вентиляторов
– Блоки питания 1+1 DC или AC
– Вводы питания находятся сзади
• Емкость
– 4 отсека
• 1 процессор+3 линейные карты или
• 2 процессора и 2 линейные карты
– До 360Gbps (полный дуплекс) с 3-х карт
Платформа MX80 - новое шасси MX на
основе Trio
Fixed and Modular Versions
 Производительность 70Gbps+
 Модульный: 2 слота, SyncE, 1588
 Фиксированный: 48x10/100/1000
 Модульный: 2 слота MIC

Experience & Economics

 Иерархическая буферизация
 Защита инвестиций
 L2/MPLS control plane
 Функциональность Junos
Варианты исполнения MX80
Модульный - MX80 «Фиксированный» - MX80-48T
• 2 слота для установки MIC
48x1 RJ-45 ports
• 20x1SFP, 2x10 XFP, 40x1 RJ-45
• на 8 портов больше, чем MIC
• 100FX, 100BX
• 10/100/1000
• 4 встроенных порта 10GE XFP
4 встроенных порта 10GE XFP
• Слот для установки сервисного
модуля Слот для установки сервисного
модуля
• 2 UART ports (Clock input/output),
BITS input Per Port Queuing
• Hierarchical QoS (per VLAN
queuing)
• License based queues
• Synchronous Ethernet enabled
Распределённая подсистема коммутации
MX

PFE WAN
WAN PFE
Матрица
коммутации
WAN PFE PFE WAN

 Буферизация выполняется на входном и на

выходном комплексах коммутации (PFE)
 Простая, масштабируемая архитектура
 Архитектура подсистемы коммутации
 2 или 3 модуля коммутации
Активные
SF
Switch Control Board = SCB
I  Неблокируемая связь
I SCB «каждый с каждым»
I I SF
I
 Полное резервирование SCB
I I  В ситуации аварии система
I I продолжает работать с
I I
меньшей
I I
C1 производительностью
DP
C2 I
DP I  Сохранение порядка
C3
DP следования пакетов
I Резервный  Обеспечение QoS на всех
2
C1 компонентах подсистемы
DP
коммутации
 4 активных плоскости коммутации (по две  На комплексе коммутации
на SCB)  На выходе с комплекса
 Каждый комплекс коммутации коммутации к матрице
подключается к каждой матрице  В самой матрице
 Архитектура подсистемы управления

SCB 1 Модуль SCB 2 Модуль

управления управления
Служебный
Коммутатор (GE)

 Сеть управления с полным

резервированием от RE до
DPC
 GE каналы для
I I I I
масштабирования
 Переключение матриц I I I I

коммутации независимо от I I I I
модулей управления
I I I I

DP DP DP DP
C C C C
Несколько фактов об RE
• RE – Routing Engine – специальная карта на
маршрутизаторе МХ, которая осуществляет все функции
управления
• RE соединен специальным каналом GE с плоскостью
коммутации
• RE имеет также соединения с линейными картами (Serial и
GE)
• RE = комбинация из процессора (как правило Intel-
архитектуры), оперативной памяти и интерфейсов
управления (консоль, management ethernet)
• Встроенные интерфейс ethernet не служит для
коммутации пакетов!
Линейные карты MX
• Концентраторы портов MPC
• Концентраторы портов DPC
• Плата DPCE-X
• Плата DPCE-R
• Модули MX-FPC
• Сервисная карта MS-DPC
Варианты исполнения MX MPC
Плотность сервисов и производительность

VLAN Queue
Adv Services Edge
•VLAN Queue

MPC2-EQ
•64K IFL
•512K Queues
Enhanced Enet / MP BBE •60Gbps
•VLAN Queue
MPC2-Q
•64K IFL
Port Queue •256K I/E Queues
•60Gbps
Cost Optimized Enet MPC1-Q
•Port Queue •32K IFL
MPC2 •128K I/E Queues
•64K IFL
•30Gbps
•Port Queue
•60Gbps

MPC1
•32K IFL
•Port Queue
•30Gbps
QoS-функционал
 MX-MPC-3D – новые интерфейсные карты
Пограничные сервисы с
масштабируемостью 3D
 Бизнес, домашние, мобильные
 сервисы
 Видео, голос, SBC, IPS

Непревзойденное качество

 Иерархическая буферизация  16 x 10GbE ports

 Port, VLAN, пользователь, приложение  120 Gbps (FDX) capacity
 В 2 раза больше очередей чем у конкурентов

Соответствие стандартам IEEE

 Производительность на скорости каналов
 Голос, видео, универсальные приложения
Modular Port
Применение
Применение Concentrator (MPC)

 Subscriber Edge  Carrier Ethernet aggregation

  Video distribution networks
Business Edge
 Data center core & aggregation
 Mobile Edge
Варианты исполнения MIC

 MIC-3D-20GE-SFP
 20 портов 10/100/1000Mbps SFP
 MIC-3D-2XGE-XFP
 2 порта 10GE XFP
 Поддержка выбора настройки WAN либо LAN-PHY фрейминга
 MIC-3D-4XGE-XFP
 4 порта 10GE XFP
 Поддержка выбора настройки WAN либо LAN-PHY фрейминга
 Важно! Не поддерживается в картах MPC-1
 MIC-3D-40GE-TX
 40 портов 10/100/1000Mbps RJ-45
 Один MIC занимает оба слота MPC
 Интерфейсная карта MPC-3D-16XGE-SFPP
• Самая высокая в индустрии плотность интерфейсов 10GE на слот
маршрутизатора
• Устанавливается в MX960, MX480 и MX240
• Фиксированная архитектура
– 16 портов 10GE SFP+
– Построена на 4х Junos Trio PFE
– Пропускная способность 120Gbps/слот при использовании всех
фабрик коммутации
(80Gbps /слот – в случае резервирования SCB)
Функциональность аналогична картам MPC2
– Поддержка только LAN-PHY фрейминга
• Варианты применения
– Carrier Ethernet aggregation
– Video distribution networks
– Data center core & aggregation
– Business edge
JUNOS Trio: Сетевой процессор (NISP)
Процессоры общего назначения
 Очень гибкие
× Низкая производительность, плотность,
питание

Программируемые матрицы (FPGAs)

 Быстрая разработка, модернизация
 Низкие затраты на разработку
JUNOS® TRIO CHIPSET Vs. × Низкая производительность, плотность,
питание
• Модульный × Высокая стоимость

• Сетевой Стандартные сетевые процессоры

процессор  Гибкие
 Быстрая разработка
• Масштабируе- × Обычно не хватает функциональности
мость“3D” × Обычно не хватает производительности и
высокое потребление
JUNOS Trio: “3D масштабирование”
Пропускная способность
Dense, Line rate 10GbEs, 100GbE

Количество подключений
Fixed and Mobile Users

Количество сервисов
Quality of Experience In-Line Services
 Juniper MX960
MX и JUNOS Trio
непревзойденная масштабируемость и гибкость
Единая Операционная Система и Оборудование
2.5 Terabits
2.6Tb/s

2 Terabits Juniper
MX480

1.5
Terabits
1.4 Tb/s
Экономика
1 Terabits
Juniper
MX240 Отдача
Juniper
500 Gb/s MX80
480Gb/s
80Gb/s Емкость
100 Gb/s

8 24 72 132

Плотность портов10GE
16х10GE карта.
Производительность Trio – 70Gbps.
В Mpps – около 55 Mpps.

Производительность распределятся
равномерно между интерфейсом к фабрике и
интерфейсом к физическим интерфейсам.

Соответственно на платформе без фабрики

пользовательским интерфейсам будет доступна
вся пропускная способность Trio.

При учете трафика с фабрикой коммутации на

каждом комплексе (каждом PFE)
неблокируемыми являются 3 порта.

Для некоторых приложений оказывается

вполне реалистичным дизайн в котором будет
наблюдается тенденция к локализации трафика
внутри каждого PFE и минимизация выхода
трафика в фабрику.

В подобный конфигурациях вся пропускная

способность Trio – 70Gbps доступна четырем
портам на этом PFE – все 4 порта становятся
line-rate. Приложения – Маршрутизатор
Границы сети, Датацентр и т.п.

Не имеет “Q” аналога – управление очередями

только на физическом интерфейсе.

Поддерживается только LAN WHY (WAN PHY

фреймер отсутствует на карте)
 Trio® 16х10GE карта архитектура.

LU fabri
4x10G c
MQ
LU fabri
4x10G c
MQ

LU fabri
4x10G
MQ
c

4x10G LU

fabri
MQ c

Для получения максимальной производительности важен дизайн сети.

Нет IX, нет QX, нет WAN PHY фреймера. Переподпиской управляет MQ.
Маршрутизаторы АСХ
 ACX Series - building blocks
RE

Ukernel Host path

4 5 6 7

0 1 2 3
1G
Wintegra NP N X 1G
BRCM PFE
16xT1E1

1G 2x10G
Timing FPGA
2x10G

Service FPGA
ACX 1000
ACX-1000 (FORTIUS-F)
Highlights
 Lower cost member of ACX family
 Provides 12 – 1 Gig and 8 – T1/E1 ports
 Offers Dual input DC [ Feed redundancy]

PICs:
 8xT1/E1 –Circuit Emulation PIC [Builtin PIC 0]
 8x1GE-Copper [Builtin PIC 1]
 4x1GE-RJ45/SFP COMBO [Builtin PIC 2]
ACX 2000
ACX-2000 Chassis (Fortius-G)
RS232
Manage DE-15 alarm FPC0, PIC1
Port FPC0, PIC2
DC Inlet Port console 6x1GE Cu + 2x1GE POE 2x1GE SFP

81 93 5
10 7
11 9
12 11
13 13
14 15
15 41 53 65 77

00 21 24 36 48 10
5 12
6 14
7 00 12 24 63 SFP0 SFP1 SFP+0 SFP+1

USB 2.0 GPS FPC 0, PIC 0 FPC0, PIC3

Sys LED 16x T1/E1 2x 1GE/10GE
BITS

FRONT

REAR
ACX-2000 Chassis (Fortius-G)
Highlights
 Provides 16xTDM, 12xGE and 2x10GE interfaces
 Provides 2 65W POE ports capable of powering all 5 classes of IEEE 803.af
PD’s (Powered Devices)
 POE is offered on Ports 0/1/3 and 0/1/7
 Offers Dual input DC power supply

PICs
 16xT1/E1 –Circuit Emulation PIC [Builtin PIC 0]
 8x1GE-Copper (PoE on 2 ports) [Builtin PIC 1]
 2x1GE-SFP [Builtin PIC 2]
 2x10GE-SFP+ [Builtin PIC 3]
ACX 4000
ACX4000 (FORTIUS M) – [12.3R1]

MIC0 MIC1

SFP + 8 Ports GE Combo

DE-15 Alarm

PSU0 PSU1 USB 2.0 MGMT Console BITS GPS SFP SFP + FAN TRAY
ACX4000 (FORTIUS M) – [12.3R1]
Highlights
 2.5 RU chassis with number of configurable plug-in modules
o Fixed portion of chassis is 8xGE combo ports
 Support for two modular power supplies offering 1+1 power supply
redundancy
o Two power supplies work in load sharing mode.
o When one fails, other takes over completely
 Offers AC and DC inputs with POE option
PICs
 8x1GE –Combo [ Builtin PIC 0]
 2x1GE- SFP [Builtin PIC 1]
 2x10GE-SFP+ [Builtin PIC 2]
 2 pluggable MIC slots
ACX 4000 – PLUGGABLE MICs
6X1GE RJ45/SFP MIC [12.3 R1]

• 6 GE Combo ports RJ45 or SFP

• Speed 10/100/1000 configurable for RJ45 port
through CLI
• SFP is always GE speed
• Media type selection between RJ45 or SFP. Default
SFP.
• POE supported on all RJ45 ports
• POE power per port 30W, system wide 170W
1XOC12/4XOC3 MIC [12.3 R1]

• Multi-rate OC12 or OC3 support

• In OC12 mode supports 1 port, OC3 mode supports 4
ports
• OC12/OC3 speed is software configurable
• OC12/OC3 channelized to DS0
• Supports SATOP application
• SONET/SDH 1+1 APS
ACX FAMILY - FEATURES
ACX FAMILY - KEY FEATURES
 ASMP mode of operation with resource partitioning for
independent operation
– RE runs on Core-0
– PFE runs on Core-1
 Flash swizzle feature for uboot/loader redundancy
 Dual-root partitioning for improved resilience
 Auto-Configuration using autod [Similar to SRX]
 Dying-Gasp support [last gasp]
 Support for chassis level Alarm-Relay
– Alarm Relay Inputs – New infrastructure
– Alarm Relay Outputs - Existing infrastructure
ACX FAMILY - KEY FEATURES (CONTD..)

 Extended operating temperature with Fan-less design

 Support for network timing with Brilliant FPGA solution
 Anti cloning technology using RENESAS chipset
 Heater module for SFPs [hardware controlled]
 No boot-rom-monitor for PFE. Chassisd launches PFE on ACX
series
– “noboot” command is not supported on ACX series
 NAND Flash based storage [No movable parts]
 NEBS Level 3 Certification – EMI Class-A
ACX FAMILY – SYSTEM LED

 The system LED doubles up as the alarm LED.

 LED behavior is illustrated in the table below

LED Color Meaning

Solid Green OK
Flashing Green System Booting Up
Solid Red RED Alarm
Flashing Red Yellow Alarm
ACX FAMILY COMPARISON

ACX-1000 ACX-2000 ACX-4000

Height 1 RU 1 RU 2.5 RU

Depth 9.5 inches 9.5 inches 9.5 inches

Width 17 inches  17 inches 17 inches

Operating -40C to +65C -40C to +65C -40C to +65C

Temperature
Control 1 x RJ45 Ethernet 1 x RJ45 Ethernet 1 x RJ45 Ethernet
ports 1 x RJ45 RS232 1 x RJ45 RS232 1 x RJ45 RS232
1 x USB at 2W each 2 x USB at 2W each 2 x USB at 2W each
1 DE15 alarm port 1 DE15 alarm port 1 DE15 alarm port
(4 outputs, 4 (4 outputs, 4 (4 outputs, 4
inputs) inputs) inputs)
 ACX FAMILY COMPARISON

ACX-1000 ACX-2000 ACX-4000

Power Fixed DC with Fixed DC with Pluggable AC & DC

redundant feed only redundant feed only hot swappable
DC Range Single unit to Single unit to support AC range 90-240V
support +18V to +18V to +30V, -39V to Single unit to support
+30V, -39V to -56V -56V +18V to +30V, -39V to
>10ms last gasp >10ms last gasp -72V
warning warning >5ms last gasp
No mix and match No mix and match warning
different input different input voltage No mix and match
voltage range range

Cooling/Airflow Passive Passive Active cooling, hot

(No FAN)  (No FAN) swap fan tray,
replaceable filter
 ACX FAMILY COMPARISON

  ACX-1000 ACX-2000 ACX-4000

Clock Sync GPS 10Mhz in/out GPS 10Mhz in/out GPS 10Mhz in/out
External N/A T1/E1 BITS T1/E1 BITS
Timing
Reference
1588v2 1588 + 1pps in/out 1588 + 1pps in/out 1588 + 1pps in/out
Synch-E Supported on all Data Supported on all Data Supported on all Data
ports ports ports
Redundant Single oscillator Single oscillator Single oscillator
clock Automatic switch Automatic switch Automatic switch
over upon bad over upon bad over upon bad
primary reference. primary reference. primary reference.
(ST3E) (ST3E) (ST3E)
ACX FAMILY COMPARISON

Data Port   ACX-1000 ACX-2000 ACX-4000

10/100/1000 M RJ-45 8 8 N/A(MIC based)

T1/E1 8 16 N/A(MIC based)

1GE SFP/RJ45 combo 4 N/A 8

1GE SFP/10G SFP+ N/A 2+2 2+2

1G SFP Modules SX, LX, LH / ZX SX, LX, LH / ZX SX, LX, LH / ZX

PoE Not Supported Supported Supported

Plugin Modules N/A N/A 16xT1/E1,

1xOC12/4xOC3,
6x1GE (SFP/RJ45)
 ACX FAMILY COMPARISON
RE/PFE
Configuration ACX-1000 ACX-2000 ACX-4000
Processor Freescale P2020, Freescale P2020, Freescale P2020,
1Ghz,Dual Core 1Ghz,Dual Core 1Ghz,Dual Core
Memory (SDRAM) 1GB with ECC 2GB with ECC 2GB with ECC

Storage (NAND) 4GB flash 4GB flash 8 GB flash

Bootflash 8MB (upgradable 8MB (upgradable to 8MB(upgradable to

to 16MB) 16MB) 16MB)
NVRAM 128KB 128KB 128KB

PFE BCM56334 BCM56334 BCM56445

Telecom Module Wintegra WP3-SL Wintegra WP3-SL N/A(MIC based)

Redundancy None None None

PFE LAUNCH

•Fortius does not have a control board, and hence no bootrom

monitor is available in fortius for ukern launch.
•Instead, the PFE launch in fortius is controlled by chassisd via
a kernel service.
•Chassisd also uses the hardware watchdog facility in the
syscpld to monitor the PFE health.
•The watchdog timeout for hardware watchdog is 30 second.
•“noboot” command is not supported for fortius
•“set chassis images feb” is not supported for fortius; the
same is achieved by using the “pfe-launch” shell command
HEATER MODULE

•Purely hardware controlled

•The SFP harware in fortius is rated to operate from 0
to 85C, while fortius itself is rated to operate from
-40C to 70C. A heater module is included in the
hardware, and shall be activated automatically by
hardware as soon as the ambient temperature around
the SFP hardware reaches temperatures nearing 0C.
•Once the temperature rises beyond a threshold above
0C, the heater is be turned off automatically.
PFE HARDWARE OVERVIEW

RE PFE
CPU CPU

T1/E1
Telecom Timing
Module Module
T1/E1
BRCM PFE
ASIC
(X)SFP

(X)SFP
Service
RJ45
Ethernet
FPGA**
PHY
RJ45
PFE HARDWARE OVERVIEW …

•BRCM ASIC Key Features

– Integrated MAC with jumbo frame support
– Line rate forwarding
– L3 routing (IP, MPLS)
– L2 switching
– VLAN, Ingress & Egress ACLs
– 802.1p & Diffserv QoS with 8 Queues per port*
•ACX1000, ACX2000
– 1st generation BRCM ASIC (PFE-1)
•ACX4000 – 12.3
– 2nd generation BRCM ASIC (PFE-2)

* HQOS in PFE-2
PFE HARDWARE OVERVIEW …

Ingress Pipeline
Packet VFP L2/L3 IFP
Parser (pre-filtering) Switching (filtering)

MAC

EFP Packet Traffic Buffer

(post-filtering) Modification Management Management

Egress Pipeline

Packet Processing Pipeline

INTERFACES

•Attachment Circuit (AC) / UNI

– Ethernet
– TDM
– ATM

•NNI
– Ethernet

NOTE: TDM & ATM interfaces covered in TDM/ATM ToI

ETHERNET INTERFACES
UNI NNI
Encapsulation Ethernet II Ethernet II
Ethernet CCC
VLAN CCC
Flexible Ethernet Services
VLAN Tagging Mode Untagged Untagged
VLAN Tagging VLAN Tagging
Stacked VLAN Tagging Stacked VLAN Tagging
Flexible VLAN Tagging Flexible VLAN Tagging
Services IPv4 IPv4
Ethernet PW MPLS Transport
IPv4 FORWARDING

 Basic IPv4 unicast forwarding functionality on par with

traditional Juniper routers
• IPv4 forwarding in hardware
• Terminating/originating packets to/from RE
• Exception packet handling & ICMP responses
• ARP support for Ethernet interfaces

OSPF, ISIS, RIP, BGP support

(on par with other Juniper routers)
IPv4 FORWARDING …

•BRCM PFE Forwarding Tables:

– Full match table
• hash-based index table
• can store only /32 routes
– Longest Prefix Match (LPM) table
• TCAM based
• can store prefix of any length

• IP fragmentation is done in software (in RE) – BRCM ASIC

limitation
• IPv6 support – under development starting 12.3
• No support for IP multicast forwarding
MPLS TRANSPORT
•P2P LSPs
•Ingress & Egress Label Edge Router (LER)
•Label Switching Router (LSR)
•Dynamic LSPs
– LDP signaling
– RSVP-TE signaling
•Static LSP
•No support for P2MP LSP at FRS
MPLS TRANSPORT …

•MPLS label operations

– POP – up to 2 labels
– SWAP
– PUSH – max of 3 labels can be pushed, of which the inner most label
has to be a VC or VPN label
– SWAP and PUSH – up to 2 labels can be pushed
– Penultimate Hop Pop (PHP)
– Explicit NULL

•TTL processing
– Support for uniform and pipe modes
– No support for per-LSP TTL mode configuration
MPLS TRANSPORT – RESILIENCY
Protection Mechanisms Triggers
 Path Protection  Link Down
 Primary & Secondary Paths  Port Level CFM (10ms)
 Local Protection (FRR)  Protocol Level BFD
 1:1 / fast-reroute
 N:1 / facility backup
 link protection
 node-link protection
Protected LSP
Pr
im
P1 P2 Pa ary
th

PE1 PE2 CE2

CE1 link protection node protection
1:1 bypass bypass
detour LSP LSP

th ry
P3 P4

Pa nda
co
Se
MPLS SERVICES …
•Ethernet PW
– Supported VC Types:
• Type 4 – tagged mode
• Type 5 – raw mode
– VLANID rewrites are supported at ingress & egress
• Only outer tag can be rewritten in the case of double-tagged packets
•PW Signaling
– LDP – l2circuit
– BGP – l2vpn
•Support for control-word and no-control-word signaling and
negotiation
• No support for family TCC
MPLS SERVICES – RESILIENCY …
PW Protection Mechanisms Triggers
 Protect Interface CFM (10ms)
AC redundancy  Ethernet PW (connection
 Redundant PW protection)
 Cold Standby Mode LSP Down
 Hot Standby Mode PW Down

ry
rima
P PW
P1 PE2

Primary
CE1 PE1 CE2
Protect
Ba PW

P2 PE3
ck
up
MPLS SERVICES …

•No support for

– PW egress protection
– PW stitching
– l2circuit local switching
HOST PATH

 17 CPU-facing queues used for host bound packets

– latency requirements (CFM/BFD)
– packet priority (network-control, best-effort)
– NH type (NH_RECEIVE, NH_RESOLVE, NH_REJECT)
– packet type (L2 BCAST, exception)
 Queue servicing
– CFM & BFD queues are low-latency queues and serviced in interrupt
context
– Other queues are serviced in thread context in round-robin order
 Queues are shaped/rate-limited based on host processing
capability & scaling requirements
– DoS attack protection
STATISTICS

•IFD (port-level) statistics

•IFL statistics (ingress/egress packet/byte counters)

only for statistics-enabled IFLs on Ethernet ports
– PFE ASIC does not have packet/byte counter resources for
all IFLs in the system
– IFL statistics supported on 16 user selected IFLs – PFE
ASIC limitation*
• Filters can be configured to get additional statistics – 97
on ingress, 47 on egress
* PFE-2 has solution
STATISTICS …

•Ethernet PW – ingress/egress packet/byte counters

•MPLS LSP – ingress/egress packet/byte counters
•PFE statistics - discarded packets
•No support for:
– IFL – packet/byte rate counters
– Ethernet PW – packet/byte rate counters
SCALING
Parameter & PERFORMANCE Scale/Value
IFLs (L3 & PW) 1K
IPv4 Routes (full match i.e. /32 prefix) 8K*
IPv4 Routes (LPM) 12K
ARP Entries 7K
MPLS Label Routes 3K
LSPs 1K
PWs 1K
Forwarding PPS performance Line rate at all packet sizes

* full match routes can also be added to the LPM table, so the
max number of such routes will be 20K
CONFIGURATION

•Configuration of interfaces & forwarding features

similar to traditional JUNOS routers
•New configuration knob
– Enabling statistics on IFLs
[edit interfaces]
ge-0/0/0 {
unit 0 {
+ statistics;
}
}
PFE HARDWARE OVERVIEW …
Ingress Pipeline
Packet VFP L2/L3 IFP
Parser (pre-filtering) Switching (filtering)

MAC

EFP Packet Traffic Buffer

(post-filtering) Modification Management Management

Egress Pipeline

Broadcom PFE Packet Processing Pipeline

Fortius PFE – Firewall implementation

Ingress Path

VFP (1K) IFP (2K)

L2/L3
1024 2048 Entries
Looku
Entries #8 Groups
p and
#4 Groups (256 x 8 )
FWDi
(256 x 4 ) ng

M
M
U
EFP(512)
512 Entries Egress
#4 Groups Processing
(128 x 4)
Egress Rewrites

Egress Path

 IFP (Ingress Filter Processor) – For Input Firewall Filters

 EFP (Egress Filter Processor) – For Output Firewall Filters
 VFP (VLAN Filter Processor) – For Default/physical interface semantic input filters
Firewall – Filters
Filter support on Ethernet IFLs based on the configured family.
Each family has its own set of match conditions and actions.
Filters are supported in the following families
• inet
• ccc
• mpls
• any – can be attached to interfaces directly at ifl level

Firewall filter supports the following semantics

• default
• interface-specific – must for outbound filter
• Physical-interface-specific
• Implicit-filters – used by CFM

Following match conditions are unsupported

• except option
• list/range of values, FC, PLP, interface-set/group
• next-term
Firewall – inet family (supported match and actions)
Configuration:
• firewall { family inet { filter <filter-name> { term <term-name> {
• from {
• source-address { <prefix>; }
• destination-address { <prefix>; }
• dscp <value>;
• precedence <value>;
• ip-options any;
• fragment-flags <value>;
• protocol <value>;
• ttl <value>;
• icmp-type <value>;
• icmp-code <value>;
• source-port <value>;
• destination-port <value>;
• tcp-initial;
• tcp-flags <value>;}
• then {
• discard;
• count <counter-name>;
• log; syslog;
• port-mirror;
• policer <policer-name>;
• three-color-policer single-rate/two-rate <policer-name>;
• loss-priority <value>;
• forwarding-class <value>;
• reject <value>;
– } } } } }

• * Note: Specifying action with loss-priority/forwarding-class specifies a MF classifier and the

MF-classifier will take precedence over CoS BA/Fixed Classification
Firewall – mpls family (supported match and actions)
Configuration:

• firewall {
• family mpls {
• filter <filter-name> {
• term <term-name> {
• from {
• exp <value>;
• }
• then {
• discard;
• count <counter-name>;
• policer <policer-name>;
• loss-priority <value>;
• forwarding-class <value>
• three-color-policer single-rate/two-rate <policer-name>;
• }
• }
• }
• }
• }
• * Note: Specifying action with loss-priority/forwarding-class specifies a MF classifier and
the MF-classifier will take precedence over CoS BA/Fixed Classification
Firewall – ccc family (supported match and actions)
Configuration:
• firewall {
• family ccc {
• filter <filter-name> {
• term <term-name> {
• from {
• NONE
• }
• then {
• count <counter-name>;
• loss-priority <value>;
• forwarding-class <value>;
• discard;
• policer <policer-name>;
• three-color-policer single-rate/two-rate<policer-name>;
• }
• }
• }
• }
• }

• * Note: Specifying action with loss-priority/forwarding-class specifies a MF classifier and

the MF-classifier will take precedence over CoS BA/Fixed Classification.
Firewall – any family (supported match and actions)
Configuration:

• firewall {
• family any{
• filter <filter-name> {
• term <term-name> {
• from {
• NONE
• }
• then {
• count <counter-name>;
• loss-priority <value>;
• forwarding-class <value>;
• discard;
• policer <policer-name>;
• three-color-policer single-rate/two-rate<policer-name>;
• }
• }
• }
• }
• }
• * Note: Specifying action with loss-priority/forwarding-class specifies a MF classifier
and the MF-classifier will take precedence over CoS BA/Fixed Classification
Applying the Firewall filter
Following filters are be applied at IFF level.( input or/and output )
• inet
• ccc
• mpls

Filter family any is applied at IFL level.( input or/and output)

Firewall Policers
Fortius supports the following policer flavors
• single-rate two color policer
• single-rate tri-color policer
• two-rate tri-color policer

Policer can be term-specific or filter-specific

System wide ARP policer is always on, to police @ 15000bps.
Per IFL ARP policer is supported.
Policer can be applied only as filter action. Policer at IFF is
unsupported. (Exception : ARP policer)
Following flavors are unsupported
• Hierarchical policer
• Layer-2 Policer
• Logical-interface-policer
Firewall – policer
Configuration:
• firewall {
• policer <policer-name> {
• if-exceeding {
• bandwidth-limit <value>;
• burst-size-limit <value>;
• }
• then {
• discard;
• loss-priority <value>;
• forwarding-class <value>;
• }
• }
• }
• firewall {
• three-color-policer <policer-name> {
• action {
• loss-priority high then discard;
• }
• two-rate/single-rate {
• color-aware/color-blind;
• committed-information-rate <value>;
• committed-burst-size <value>;
• peak-information-rate <value>;
• peak-burst-size <value>;
• }
• }
• }
Firewall Port-mirroring
Fortius supports port-mirroring for inet family on the input direction.
Locally Mirrored, single next-hop is supported
Maximum mirror capacity is 1G
Following flavors are unsupported
• Remote mirroring
• Sampling
• Next-hop-groups
• Multiple instances
• Outbound mirroring
Firewall – port-mirroring

• port-mirroring {
input {
rate 1;
}
family inet {
output {
interface ge-0/1/1.0 {
next-hop 20.20.20.3;
}
}
}
}
Scale Limits
Inbound Scale
Max Terms ( family : inet/ccc) 249 [IFP]
Max Terms (family : mpls) 124 [IFP]
Max Terms (family : any) 98 [IFP], 254[VFP]
ARP Policers 63 [IFP]
Outbound Scale/Value
Max Terms ( family : inet/ccc) 126[EFP]
Max Terms (family : any) 47[EFP]
Note:
 Default and physical interface specific semantic will consume only one hardware
instance if the filter is used from IFP. Multiple attachments of same default-semantics
filter will use the VFP space (1 per attachment). (MAX=254 entries/254 attachments)
System overview

– Fortius F/G can support a maximum of 8 forwarding classes.

– Also, every port can have a maximum of 8 egress queues.

– By default, 4 forwarding classes are defined, and 4 egress queues are provisioned for each port.

– The system has a global forwarding-class to queue mapping scheme.

– PLP can have one of the 3 (low, med-high or high) possible values.

– The system has an internal buffer of 2MB and buffer limits are enforced based on egress queues.

– The CoS/Firewall features supported are listed in the subsequent slides.

 Ingress features in the ascending order of priority:
CoS and Firewall on Fortius F/G platforms

BA classifiers

Fixed classifiers

MF Filters/ Policers
 Egress features:
CoS and Firewall on Fortius F/G platforms

Egress queue based buffer management

WRED

Queue Scheduling

Queue shaping

Queue statistics

Port shaping

Egress BA rewrites

Egress policer and filters

Behavior Aggregate (BA) Classifiers

BA classifiers assign the FC and PLP for the packet based

on the CoS code-points in the packet.

BA classifiers are supported only on Ethernet interfaces.

Classification based on the following packet fields is

supported:
– IPv4 - inet-precedence/ DSCP
– ieee-802.1p of single/outer and inner VLAN tag in ethernet
payload
– MPLS EXP
Behavior Aggregate (BA) Classifiers – inet-prec/dscp

– inet-prec/DSCP classifiers derive the FC and PLP based on the inet-prec ToS/DSCP code-
point in the IP header of the packet.

– On Fortius the same hardware table is used to implement both inet-prec as well as DSCP
classification.

– Inet-prec/DSCP classifiers are bound at the port (IFD), unlike traditional Junos platforms
where they are bound to logical interfaces (IFL).

– Applies on the following packets:

- IP routed packets.
- Ether-CCC and VLAN-CCC packets with IPv4/IPv6 payload.

Note: inet-prec and DSCP classifiers are mutually exclusive.

Behavior Aggregate (BA) Classifiers – inet-prec/DSCP Config
1) Define the classifier

[edit class-of-service]
classifiers {
(inet-prec|dscp) <classifier-name> {
forwarding-class <fc> loss-priority [low | high] code-points <>;
}
}

2) Attach the classifier:

To support port (IFD) based classifiers, the following new CLI bindpoint is supported.

set class-of-service interfaces <if_name> classifiers [inet-prec|dscp]

<classifier_name>
Behavior Aggregate (BA) Classifiers – ieee-802.1p
– Ieee-802.1p classifiers derive the FC and PLP based on the 802.1p bits in the VLAN-tag.
– The 802.1p bits can be picked from inner or outer VLAN tag based on the user
configuration.

– Ieee-802.1p classifiers are bound at the port (IFD), unlike traditional Junos platforms
where they are bound to logical interfaces (IFL).

– Applies on the following packets:

- IP routed packets.
- Ether-CCC and VLAN-CCC packets
- MPLS label-switched packets.

– Ieee-802.1p has a lower precedence that inet-prec/DSCP and EXP classifiers. i.e when
both inet-prec and ieee-802.1p classifier are configured on an IFD, for an IP routed packet,
the FC and PLP are derived based in the inet-prec ToS byte and not based on the 802.1p
bits.
Behavior Aggregate (BA) Classifiers – ieee-802.1 Config
1) Define the classifier

[edit class-of-service]
classifiers {
(inet-precedence | dscp) <classifier-name> {
forwarding-class <fc> loss-priority [low | high] code-points <>;
}
}

2) Attach the classifier:

To support port (IFD) based ieee-802.1p classifiers, the following new CLI bindpoint
is supported.
set class-of-service interfaces <if_name> classifiers ieee-802.1
[vlan-tag (inner|outer)] <classifier_name>

Note: 'ieee-802.1 vlan-tag outer' and ieee-802.1 have the same

functionality and both cannot be configured together.
Behavior Aggregate (BA) Classifiers – EXP

– EXP classifiers derive the FC and PLP based on the EXP bits.

– Classification is based on the EXP bits of the outermost label

always.

– EXP classifiers are bound at the system level (system-defaults),

unlike traditional Junos platforms where they are bound to
logical interfaces (IFL).

– Applies on the following packets:

- Packets that are MPLS popped or swapped.
Behavior Aggregate (BA) Classifiers – EXP Config
1) Define the classifier

[edit class-of-service]
classifiers {
exp <classifier-name> {
forwarding-class <fc> loss-priority [low | high] code-points <>;
}
}

2) Attach the classifier:

To support system-wide EXP classifiers, the following new CLI bindpoint is
supported.
set class-of-service system-default classifiers exp <classifier_name>
Behavior Aggregate (BA) Classifiers – Monitoring and Debugging

RE:
Show class-of-service forwarding-table classifier
Use the
Show following commands
class-of-service to seeclassifier
forwarding-table what classifiers
mapping are
actually sent to the kernel by Cosd:

PFE:
Show ifl brief
Use the following commands to see what classifiers are
Show ifd brief
actually
Show bound in the PFE and the hardware resources that
cos classifier
Show cos classifier binding
are used:
Show cos halp classifier [dot1p | exp]
debug cos halp-acx classifier
Fixed Classifiers

– Fixed classifiers assign the FC for the packet based on the logical
interface the packet is received on.
– The PLP cannot be configured and is always set to low.

– Fixed classifiers can be applied on both Ethernet logical

interfaces as well as T1/E1 interfaces.

– Fixed classifiers take precedence over BA classifiers.

– Fixed classifiers can be configured only up to 190 Ethernet IFLs.

– Fixed classifiers can be configured on any number of T1/E1 IFLs.
Fixed Classifiers – Config and Debug
Config:

• [edit class-of-service]
• interfaces {
• <interface-name> {
• unit <> {
• forwarding-class <fc>;
• }
• }
• }

PFE debug:

Show cos halp fixed-classifier

Multifield (MF) Classifiers and Policers

– MF classifiers assign the FC and PLP for the packet based on supported fields in the
packet header.

– MF classifiers are attached per IFL.

– MF classifiers have higher precedence than BA classifiers as well as Fixed classifiers.

– Policers are attached to IFLs and police traffic based on supported packet fields.

– MF classifiers and policers are configured through the “firewall” hierarchy and will be
described in detail in the Firewall section.

– Please refer the Firewall-TOI to know more details about the MF classifier and
policers.
 Forwarding class to queue mapping
• Up to eight forwarding classes can be defined globally.
• Four forwarding classes are defined by default (see below CLI o/p).
• There is a one-to-one mapping between the forwarding class and the queue number
which is displayed using the following command.
regress@fortius-g11# run show class-of-service forwarding-class
Forwarding class ID Queue Restricted queue Fabric priority Policing priority SPU priority
best-effort 0 0 0 low normal low
expedited-forwarding 1 1 1 low normal low
•The definition of the forwarding class specifies the
assured-forwarding
network-control
2
3
2
3
2
3
low
low
normal
normal
low
low

queue id
More forwarding classes can be defined by specifying a queue for the forwarding class
as below:
regress@fortius-g11# set class-of-service forwarding-classes class
new_fwding_class queue-num 4

More than one forwarding classes can use the same queue:
regress@fortius-g11# run show class-of-service forwarding-class
Forwarding class ID Queue Restricted queue Fabric priority Policing priority SPU priority
best-effort 0 0 0 low normal low
expedited-forwarding 1 1 1 low normal low
assured-forwarding 2 2 2 low normal low
network-control 3 3 3 low normal low
new_fwding_class 4 7 3 low normal low
new_fwding_class2 5 7 3 low normal low
new_fwding_class3 6 7 3 low normal low
new_fwding_class4 7 7 3 low normal low
Egress Buffer Management
- Fortius has a total of 2MB of internal buffers shared across all the egress
queues of the Ethernet ports of the system.
- Each egress queue has access to reserved and shared space, the former
being the guaranteed amount of buffers for the particular queue and
the latter being the buffers shared across all the ‘active’ queues of the
system.
- The shared space for a particular queue is not guaranteed, but Fortius
uses an intelligent buffer management algorithm which tries to ensure
that all ‘active’ queues get fair access to the shared space.
- By default, each egress Ethernet port has access to 100us of reserved
buffer space which are distributed across its egress queues.
- The default scheduler-map allocated 95% of the port’s buffer space to
best-effort and 5% to network-control.
- The JunOS buffer-size configuration allows the user to configure the
amount of reserved space per egress queue.
Egress Buffer Management Config

1) Define the buffer-size for a particular scheduler using the appropriate knob. The
exact and temporal knobs turn off the shared buffer space usage. The percent
knob allocates a greater share of the port’s 100us reserved space to the
configured queue

[edit class-of-service]
regress@fortius-f-svl6# set schedulers s1 buffer-size ?
Possible completions:
exact Enforce exact buffer size
percent Buffer size as a percentage (0..100)
> remainder Remainder of buffer size available
temporal Buffer size as temporal value (microseconds)
[edit class-of-service]

2) Associate scheduler with a forwarding-class, scheduler-map and attach to an

interface
[edit class-of-service]
regress@fortius-f-svl6# set scheduler-maps sm1 forwarding-class best-
effort scheduler s1

[edit class-of-service]
regress@fortius-f-svl6# set interfaces ge-0/1/5 scheduler-map sm1
Egress Buffer Management PFE debug

1) When the buffer configuration is changed, the current available counts are
printed on the PFE console
[Dec 29 22:04:31.855 LOG: Debug] bcm563xx_mmu_dump: res_cell: 1564, res_pkts: 527,
shr_cell: 14820, shr_pkts:5617
[Dec 29 22:04:31.855 LOG: Debug] bcm563xx_mmu_dump: res_cell: 1560, res_pkts: 526,
shr_cell: 14824, shr_pkts:5618
[Dec 29 22:04:31.872 LOG: Debug] bcm563xx_mmu_dump: res_cell: 1652, res_pkts: 560,
shr_cell: 14732, shr_pkts:5584
[Dec 29 22:04:31.872 LOG: Debug] bcm563xx_mmu_dump: res_cell: 1656, res_pkts: 561,
shr_cell: 14728, shr_pkts:5583

2) If the system is out of buffers then the error message is printed on the PFE
console. Also monitor the /var/log/messages for any error debugs
FFEB(fortius-f-svl6 vty)#
[Dec 29 22:05:46.443 LOG: Debug] bcm563xx_mmu_dump: res_cell: 1564, res_pkts: 527, shr_cell:
14820, shr_pkts:5617
[Dec 29 22:05:46.444 LOG: Debug] bcm563xx_mmu_dump: res_cell: 1560, res_pkts: 526, shr_cell:
14824, shr_pkts:5618
[Dec 29 22:05:46.445 LOG: Err] Out of buffers. req cells: 48828, req pkts: 18328, avail cells:
14824, avail pkts: 5618
[Dec 29 22:05:46.445 LOG: Err] ACX_COS_HALP(acx_cos_bind_sched_map_ifd:443): Delay buffer bind
failed for ifd ge-0/1/5 queue num 0
[Dec 29 22:05:46.445 LOG: Err] Delay buffer bind failed for ifd ge-0/1/5queue num 0
[Dec 29 22:05:46.446 LOG: Err] ACX_COS_HALP(acx_cos_bind_scheduler_map:526): Bind sched map failed
[Dec 29 22:05:46.446 LOG: Err] Bind sched map failed!
[Dec 29 22:05:46.446 LOG: Err] COS(cos_final_scheduler_bind_add_action:953): Platform failed to
bind scheduler map 49552 to element.cos_element_type 2 index 141)
[Dec 29 22:05:46.446 LOG: Debug] bcm563xx_mmu_dump: res_cell: 1560, res_pkts: 526, shr_cell:
14824, shr_pkts:5618
Scheduling Config
3) Configure the shaping-rate (PIR) on a scheduler
[edit class-of-service]
regress@fortius-f-svl6# set schedulers s1 shaping-rate ?
Possible completions:
<rate> Shaping rate as an absolute rate (3200..160000000000 bits per second)
percent Shaping rate as a percentage (1..100)
[edit class-of-service]

4) Associate scheduler with a forwarding-class, scheduler-map and attach to an

interface
[edit class-of-service]
regress@fortius-f-svl6# set scheduler-maps sm1 forwarding-class best-
effort scheduler s1

[edit class-of-service]
regress@fortius-f-svl6# set interfaces ge-0/1/5 scheduler-map sm1
Scheduling

- Each egress port has a maximum of 8 egress queues mapped directly to it

- Fortius has a WDRR scheduler across the egress queues in the system

- The scheduler supports strict-high priority scheduling

- The CIR (guaranteed rate) for each of the queues can be configured using
the transmit-rate JunOS CLI

- The PIR (peak rate) for each of the queues can be configured using the
shaping-rate JunOS CLI. In addition, PIR can be configured on an
aggregate basis at the interface level.
Scheduling Config
1) Configure the transmit-rate (CIR) on a scheduler. The exact
knob sets the PIR = CIR
[edit class-of-service]
regress@fortius-f-svl6# set schedulers s1 transmit-rate ?
Possible completions:
<rate> Transmit rate as rate (3200..160000000000 bits per second)
exact Enforce exact transmit rate
percent Transmit rate as percentage (0..100)
> remainder Remainder available
[edit class-of-service]

2) Configure the strict-high priority on a scheduler

[edit class-of-service]
regress@fortius-f-svl6# set schedulers s1 priority strict-high

[edit class-of-service]
regress@fortius-f-svl6#
Scheduling Config – Interface shaper
1) A shaper can also be configured directly on the interface as shown below:

[edit class-of-service]
regress@fortius-f-svl6# show
interfaces {
ge-0/1/5 {
shaping-rate 450m;
}
}
Egress Rewrites

The FC and PLP are rewritten into CoS code-points of the

packet header using this feature.

The following fields can be written:

– Inet-prec/ToS
– Ieee-802.1p of the outer VLAN
– EXP
Egress inet-prec/DSCP Rewrite

– The FC and PLP are rewritten into DSCP/ToS code-points of the packet IP
header using this feature.

– On Fortius the same hardware table is used to implement both inet-prec as

well as DSCP rewrite.

– Inet-prec/DSCP rewrite-rules are bound at the port (IFD), unlike traditional

Junos platforms where they are bound to logical interfaces (IFL).

– Applies on the following packets:

- IP routed packets.

– inet-prec and DSCP rewrites are mutually exclusive.

Egress inet-prec/DSCP Rewrite - config
1) Define the rewrite-rule

[edit class-of-service]
rewrite-rules {
[dscp|inet-prec] <classifier-name> {
forwarding-class <fc> loss-priority [low | high] code-points <>;
}
}

2) Attach the classifier:

To support IFD based rewrite, the following new CLI bindpoint is supported.

set class-of-service interfaces <> rewrite-rules [dscp|inet-prec]

<rw_name>
Egress rewrite-rules: ieee-802.1p

– Ieee-802.1p rewrite-rules map the FC and PLP based into the 802.1p
bits in the VLAN-tag.
– The 802.1p bits can be written only on the outer VLAN tag.

– Ieee-802.1p rewrite-rules are bound at the port (IFD), unlike

traditional Junos platforms where they are bound to logical interfaces
(IFL).

– Applies on the following packets:

- IP routed packets.
- Ether-CCC and VLAN-CCC packets
- MPLS label-switched packets.
Egress rewrite-rules: ieee-802.1 Config
1) Define the rewrite-rule

[edit class-of-service]
rewrite-rules {
ieee-802.1 <classifier-name> {
forwarding-class <fc> loss-priority [low | high] code-points <>;
}
}

2) Attach the classifier:

To support IFD based rewrite, the following new CLI bindpoint is supported.

set class-of-service interfaces <> rewrite-rules ieee-802.1 <rw_name>

Egress rewrite-rules: EXP

– EXP rewrite-rules map the FC and PLP based into the EXP
bits in the MPLS label.
– EXP rewrite-rules are applied on the egress logical interface
(IFL).

Applies on the following packets:

- MPLS label-swap.
- MPLS label-push (It applies on all the pushed labels).
Egress rewrite-rules: EXP Config
1) Define the rewrite-rule

[edit class-of-service]
rewrite-rules {
exp <classifier-name> {
forwarding-class <fc> loss-priority [low | high] code-points <>;
}
}

2) Attach the rewrite-rule:

set class-of-service interfaces <> unit <> rewrite-rules exp

<rewrite_name>
Egress Rewrite-rules – Monitoring and Debugging

RE:
Use the following commands to see what rewrite-rules are
actually sent to the kernel by Cosd:
Show class-of-service forwarding-table rewrite-rules
Show class-of-service forwarding-table rewrite-rules mapping

PFE:
Use the following commands to see what classifiers are
actually bound in the PFE and the hardware resources that
are used:
Show ifl brief
Show ifd brief
Show cos rewrite
Show cos rewrite binding
show cos halp rewrite
debug cos halp-acx rewrite
Egress Policing and Filters

These are implemented as “output firewall filters”.

These are used to police and filter traffic based on

supported fields in the packet header. Policing/filtering
cannot be done based on forwarding class.

Please refer to Firewall filters for details.

Classification of CPU generated packets

– RE generated packets (eg. OSPF, PING etc):

The FC assigned to RE generated packets is based on the
“set class-of-services host-outbound ….”
set class-of-service host-outbound-traffic forwarding-class <fc>

– PFE generated packets (eg. OAM, BFD etc):

These packets will always go to queue-id 3 which by
default is named Network Control.

Note: Packets transmitted by the Hostpath (CPU) are not

always accounted in the queue statistics ‘show interface
queue ge-<x>' because of hardware limitations.
Classification of PTP packets

The following classifier is used to derive the FC and PLP for

PTP packets.
Classifier: ipprec-default, Code point type: inet-precedence, Index:
12
Code point Forwarding class Loss priority
000 be low
001 af low
010 be low
011 be low
100 be low
101 ef low
110 nc low
111 nc high

The DSCP value used for PTP packets is configured using:

set protocols ptp ipv4-dscp
Конец первого дня