nexus 7000 – архитектура передачи данных. Поиск и...

Nexus 7000 – архитектура передачи данных. Поиск и устранение неисправностей.

Blusenkov Oleksandr

Data Center Team, Cisco TAC

March, 2015

Cisco Confidential 2 © 2013-2014 Cisco and/or its affiliates. All rights reserved.

Cisco Support Community – Expert Series Webcast

Сегодня на семинаре Эксперт Cisco TAC Блусенков Александр проведет экскурс по архитектурным

особенностям Nexus 7000

Александр Блусенков

Инженер центра

технической поддержки

Cisco TAC, Брюссель


Технические Эксперты

Тема: Nexus 7000 – архитектура передачи данных. Поиск и устранение неисправностей

Дата проведения вебинара: 17 марта 2015 года

Николай Васильев



Cisco TAC в Брюсселе

Александр Нестеров



Cisco TAC в Брюсселе


Спасибо, что посетили наш вебинар сегодня

Сегодняшняя презентация включает опросы аудитории

Пожалуйста, участвуйте!


Спасибо, что присоединились к нам сегодня Скачать презентацию Вы можете по ссылке: https://supportforums.cisco.com/ru/document/12452691

https://supportforums.cisco.com/ru/document/12452691

https://supportforums.cisco.com/ru/document/12452691


Уважаемые пользователи мы предлагаем Вам

принять участие в конкурсе после проведения

вебкаста, который так и будет называться

«Nexus 7000 – архитектура передачи данных.

Поиск и устранение неисправностей».

Первые три победителя получат фирменный куб Cisco-TAC

Ответы присылайте на [email protected]

Задание конкурса будет размещено 17.03.2014 сразу после проведения вебкаста (13-30мск)

Конкурс “Nexus 7000 – архитектура передачи данных. Поиск и устранение неисправностей.”

mailto:[email protected]



Присылайте Ваши вопросы!

Используйте панель Q&A, чтобы задать вопрос. Наши эксперты ответят на них.


Вопрос №1

Приходилось ли вам использовать ethanalyser или ELAM при поиске неисправности?

a) Нет, не слышал ничего о таких инструментах

b) Слышал о существовании ethanalyser но не имею представление о ELAME

c) Слышал о ELAM, но считал это внутренним инструментарием, применяемым инженерами ТАС

d) Да, приходилось пробовать инструментарий в работе


Cisco Support Community – Expert Series Webcast

Блусенков Александр

Инженер центра технической поддержки Cisco TAC в Брюсселе

Март, 2015

Nexus 7000 – архитектура передачи данных. Поиск и устранение неисправностей.


Содержание

• Netstack

• Software packet processing component

• uRIB & uFDM

• Unicast Routing Information Base & Unicast Forwarding Distribution Manager

• L2FM & MTM

• (L2 Feature Manager & MAC Table Manager) Manages MAC addresses and MAC aging

• EthPM & Port Client

• (Ethernet Port Manager) Manages Ethernet and Port-Channel Interfaces

• VLAN Manager

• Manages VLANs and Bridge Domains

• PIXM & PIXMc

• (Port Index Manager) Manages LTL, CBL, MET and FPOE programming

• ELTM & ELTMc, IFTMc

• (EARL LIF Manager & Clients) LIF, ILM, ELM, Port Group programming


Рекомендую…

BRKRST-3066 - Troubleshooting Nexus 7000

BRKDCT-3144 - Advanced - Troubleshooting Cisco Nexus 7000 Series Switches

BRKDCT-3145 - Advanced - Troubleshooting Cisco Nexus 5000 / 2000 Series Switches

12 Cisco Confidential 12 © 2013-2014 Cisco and/or its affiliates. All rights reserved.

Netstack



• Netstack


• uRIB & uFDM


• L2FM & MTM




• VLAN Manager


• PIXM & PIXMc





NxOS Netstack

• Netstack это компонент ответственный за «обработку» in-band(*) трафика

• Примером in-band пакета может служить DHCP трафик перенаправленный на CPU (DHCP Relay), OSPF и тд.

• In-band / Management трафик в конечном итоге должен быть перенаправлен в соответствующие компоненты для дальнейшей обработки (OSPF, STP, LACP, SSH…)

• Netstack relies on many SDBs from information providing components and local caching to speed up lookups for the software in the packet path

• Multiple software queues in the packet processing path are used to support better QOS for critical functions and increased software scale

• Несколько программных очередей используются для обеспечения лучшего качества обслуживания (QoS) критически важных функций


Архитектура Netstack

• Netstack включает в себя две группы компонентов - KLM (Kernel Loadable Module) и User Space компоненты

• KLM выполняет минимальный процессинг in-band трафика для определения VDC и последующего форвардинга в PacketManager супервизора

• Поскольку User Space компоненты локальны для VDC (повышает отказоустойчивость NX-OS в целом/restartability on process crash), определение VDC «получателя» становится важной задачей

• User Space компоненты (L2/L3/L4) локальны для VDC:

• Вкачает в себя Packet Manager (L2), IP Input (L3), and TCP/UDP (L4) Functions

• PktMgr обеспечивает L2 процессинг

• IP Input & TCP / UDP предоставляют сокет интерфейс для TCP/UDP приложений

• IP Input & TCP / UDP интегрированы с IP процессингом (ARP и URIB)

• PktMgr изолирован от IP Input &TCP/UDP


Архитектура Netstack & Packet Manager

Rx

Tx

In-B

and

/ M

anag

em

ent


Netstack процессинг (Kernel)

n7k1-a11# sh sys inband queuing statistics

Inband packets unmapped to a queue: 0

Inband packets mapped to bpdu queue: 4106817

Inband packets mapped to q0: 2801346

Inband packets mapped to q1: 431228

In KLM packets mapped to bpdu: 4106817

In KLM packets mapped to arp : 5400

In KLM packets mapped to q0 : 2801346

In KLM packets mapped to q1 : 431228

In KLM packets mapped to veobc : 1896439

Inband Queues:

bpdu: recv 4106817, drop 0, congested 0 rcvbuf 2097152, sndbuf 2097152 no drop 1

(q0): recv 2801346, drop 0, congested 0 rcvbuf 2097152, sndbuf 2097152 no drop 0

(q1): recv 431228, drop 0, congested 0 rcvbuf 2097152, sndbuf 2097152 no drop 0

• Использует программные очереди для приоритезации трафика

• BPDUs имеют отдельную “no drop” очередь

• Остальной трафик делиться на High и Low

• Очереди обслуживаются WRR и имеют свои веса (BPDU - 32, Q0 - 8, Q1 - 4, Q2 - 2 Q3

- 64)

Статистика

по VDC

3 очереди между

KLM & PktMgr


Netstack Packet Процессинг (PktMgr)

• Packet Manager обрабатывает все in-band/management пакеты полученные от KLM

• L2 / Non-IP протоколы (STP, CDP, UDLD, CFS, LACP, ARP, etc) регистрируются в PktMgr напрямую и непередается непосредственно в Netstack

• IP протоколы подвязаны к netstack (IP_Input)

• RX: PktMgr отвечает за L2 декапсуляцию и последующую отпарвку к нужному клиету

• TX: PktMgr отвечает за L2 инкапсуляцию и последующую в KLM


Netstack процессинг (PktMgr)

n7k1-a11# show system internal sysmgr service all | grep stp

stp 0x0000012F 4880 171 s0009 1 N/A 1

n7k1-a11# show system internal mts sup sap 171 description

STP SAP


STP DATA SAP

n7k1-a11# show system internal pktmgr client 0x12f

Client uuid: 303, 2 filters, pid 4880

Filter 0: EthType 0x4242, Dmac 0180.c200.0000,

Rx: 1714307, Drop: 0

Filter 0: EthType 0x010b, Snap 267,Dmac 0100.0ccc.cccd,

Rx: 15846706, Drop: 0

Options: TO 0, Flags 0x1, AppId 0, Epid 0

Ctrl SAP: 171, Data SAP 177 (1)

Total Rx: 17561013, Drop: 0, Tx: 70783055, Drop: 0

Recirc Rx: 0, Drop: 0

Rx pps Inst/Max: 13/48

Tx pps Inst/Max: 44/175

COS=0 Rx: 106849, Tx: 0 COS=1 Rx: 0, Tx: 0

COS=2 Rx: 0, Tx: 0 COS=3 Rx: 0, Tx: 0

COS=4 Rx: 0, Tx: 0 COS=5 Rx: 4121466, Tx: 0

COS=6 Rx: 13332610, Tx: 70783055 COS=7 Rx: 88, Tx: 0

• STP клиент PktMgr.

• При первой инициализации STP регистрируется в PktMgr, получает свой Client ID, Ctrl SAP ID и Data SAP ID (SAP – Service Access Point (аналогия с TCP портом))

• Связь между PktMgr и STP обеспечивается по средствам MTS (Messaging and Transaction Service)

• Rx трафик от PktMgr к STP передаётся MTS у адресом получателя равным Data SAP ID

• Tx трафик от STP к PktMgr отпавляется с адресом Ctrl SAP ID

• PktMgr получает фреймы от STP и отправляет их дальше в KLM для последующей отсылки

Packet Manager

статистика

Фильтр DMAC,

Ethertype &

SNAP

Client MTS

SAP IDs


Netstack Packet Процессинг (PktMgr)

n7k1-a11# show system internal mts sup sap 177 stats msg tx: 78175827

byte tx: 15295478586

msg rx: 37820908

byte rx: 8305769224

opc sent to myself: 0

max_q_size q_len limit (soft q limit): 1024

max_q_size q_bytes limit (soft q limit): 15%

max_q_size ever reached: 0

max_fast_q_size (hard q limit): 32000

rebind count: 0

Waiting for response: none

buf in transit: 0

bytes in transit: 0

• Для передачи фреймов между Packet Manager & L2 клиентами

используется MTS инфраструктура


STP DATA SAP

N7k1-a11# show system internal pktmgr interface

e1/16

Ethernet1/16, ordinal: 160 Hash_type: 1

SUP-traffic statistics: (sent/received)

Packets: 1338123 / 41368

Bytes: 100070302 / 5875292

Instant packet rate: 1 pps / 0 pps

Packet rate limiter (Out/In): 0 pps / 0 pps

Average packet rates(1min/5min/15min/EWMA):

Packet statistics:

Tx: Unicast 0, Multicast 1338123

Broadcast 0

Rx: Unicast 0, Multicast 41368

Broadcast 0


Netstack IP Процессинг

IP process обслуживает следующие типа трафика:

1. IPV4 пакеты сгенерированные/переадресованные

в супервизор (OSPF, SSH) 2. IPV4 пакеты попавшие в glean adjacency

(отсутствует запись в ARP). 3. Передача пакетов, которые не могут быть

переданы без участия CPU (IP options, пакеты требующие фрагментации, пакеты требующие ICMP redirect, и тд.)

4. Пакеты которые должны быть удалены (при этом генерируется ICMP ошибка) (TTL failure, RPF failure, FIB miss и тд)

5. Мультикаст трафик требующий построения дерева


Netstack IP Accounting

n7k1-a11# show ip traffic

IP Software Processed Traffic Statistics

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

Transmission and reception:

Packets received: 2300394, sent: 2528710, consumed: 2285209,

Forwarded, unicast: 0, multicast: 0, Label: 0

Opts:

end: 0, nop: 0, basic security: 0, loose source route: 0

timestamp: 0, record route: 0

strict source route: 0, alert: 562,

other: 0

Errors:

Bad checksum: 0, packet too small: 0, bad version: 0,

Bad header length: 0, bad packet length: 0, bad destination: 0,

Bad ttl: 0, could not forward: 0, no buffer dropped: 0,

Bad encapsulation: 10081, no route: 799195, non-existent protocol: 0

Bad options: 0

Stateful Restart Recovery: 0, MBUF pull up fail: 0

Bad context id: 0, rpf drops: 0

Ingress option processing failed: 0 Ingress mforward failed: 367 Ingress lisp drop: 0 Ingress Drop (ifmgr init): 0,

Ingress Drop (invalid filter): 0

Ingress Drop (Invalid L2 msg): 0

ACL Filter Drops :

Ingress - 0

Egree - 0

Directed Broadcast - 0

Fragmentation/reassembly:

<snip>

• IP traffic статистика показывает кол-во фрагментированных пакетов, ICMP,

TTL и тп.


Netstack TCP / UDP

TCPUDP компонент включает в себя следующую функциональность: • TCP Stack

• UDP Stack

• Raw socket

Реализация сокета • BSD Based

• POSIX совместимый

• Стандартная non-blocking / select парадигма

• Поддержка типовых Unix приложений, таких как ping и telnet с минимальной модификацией кода сокета

• INPCB хэш таблица хранит данные о соединениях

• Сокет сохраняется при рестарте процесса Netstack (MTS Replay)

• Сокет не сохраняется при `Supervisor switchover`


Создание сокета TCP

• При получение TCP SYN Netstack создает stub INPCB запись

• Partial socket information is populated into PCB (Protocol Control Block)

• По завершению TCP three-way handshake вся о создается полный сокет – иначе говоря ТСP сессия установлена

n7k1-a11# debug sockets tcp pcb

2013 Feb 19 05:34:05.706341 netstack: syncache_insert: SYN added for L:10.116.78.227.52090 F:172.18.118.197.22,

tp:0x861e1dc inp:0x861e114

2013 Feb 19 05:34:05.731635 netstack: in_pcballoc: PCB: Allocated pcb, ipi_count: 5

2013 Feb 19 05:34:05.731719 netstack: in_pcbinshash: PCB: Insert pcb in hash lists L: 172.18.118.197.22, F: 0.0.0.0.0, C:

2

2013 Feb 19 05:34:05.731748 netstack: in_pcbrehash: PCB: Insert pcb in hash lists L: 172.18.118.197.22, F:

10.116.78.227.52090, C: 2

2013 Feb 19 05:34:05.731778 netstack: syncache_socket: Created full blown socket with F:10.116.78.227.52090

L:172.18.118.197.22 peer_mss 1260

2013 Feb 19 05:34:05.732084 netstack: in_setpeeraddr: PCB: in_setpeeraddr L 172.18.118.197.22 F 10.116.78.227.52090 C: 2


2013 Feb 19 05:34:05.876895 netstack: in_pcbremlists: PCB: Removing pcb from hash list L: 0.0.0.0.0, F: 0.0.0.0.0 C:

65535


2013 Feb 19 05:34:05.879027 netstack: in_pcbdetach: PCB: Detach L 0.0.0.0.0 F 0.0.0.0.0

2013 Feb 19 05:34:05.879063 netstack: in_pcbremlists: PCB: Removing pcb from hash list L: 0.0.0.0.0, F: 0.0.0.0.0 C:

65535


Netstack Сокет Клиенты

• Socket клиенты могут быть идентифицированы с помощью Netstack socket команд

• Можно так же идентифицировать «ненормальную работу» сокет клиентов

n7k1-a11# show sockets client detail

client: dcos_sshd, pid: 2733, sockets: 3

cancel requests: 134

cancel unblocks: 102

cancel misses: 10

select drops: 22

select wakes: 102

sockets: 2:10, 3:10, 4:10

Statistics:

socket calls: 4 connect calls: 2 connect_dispatch : 2

recvmsg_dispatch_needblock: 1 recvmsg calls: 267 sendmsg calls: 295

select calls: 998 select_dispatch: 702 select_may_need_worker: 999

close calls: 7 fcntl calls: 7 setsockopt calls: 2

getsockopt calls: 1 getpeername calls: 16 fork calls: 2

execve calls: 1 dup calls: 5 cancel calls: 134

cancelmiss: 10 cancelunblockedselect: 102 socket_ha_update calls: 2


Netstack Socket Accounting

n7k1-a11# show sockets statistics all

TCP v4 Received:

177465 total packets received, 123573 packets received in sequence,

46141873 bytes received in sequence, 69 duplicate-only packets received,

24716 duplicate-only bytes received, 8 out-of-order packets received,

416 out-of-order bytes received, 505 rcvd duplicate acks,

56944 rcvd ack packets, 10878700 bytes acked by rcvd acks,

804 Dropped no inpcb,

TCP v4 Sent:

72699 total packets sent, 59 control (SYN|FIN|RST) packets sent,

66188 data packets sent, 10882093 data bytes sent,

180 data packets retransmitted, 53588 data bytes retransmitted,

525 ack-only packets sent, 5747 window update-only packets sent,

TCP v4:

3 connections initiated, 105 connections accepted,

108 connections established, 108 conn. closed (includes drops),

65 connections dropped, 159 total rxmt timeout,

12 connections dropped in rxmt timeout, 37 keepalive timeouts,

35 keepalive probes sent, 2 connections dropped in keepalive,

TCP v4 generic

48049 segs where we tried to get rtt, 55612 times we succeeded to get rtt,

302 delayed acks sent, 1 segments dropped due to PAWS,

26786 hdr predict ok for acks, 119035 hdr predict ok for data pkts,

12 bogus SYN, e.g. premature ACK,

TCP v4 syncache

105 entry added to syncache, 105 successful extraction of entry,

• Socket accounting предоставляет статистику UDP, TCP, Raw Sockets

• Общая (по каждому Netstack) TCP drop, out-of-order & duplicate статистика


Netstack Architecture Recap

• Пакет обрабатываемы

Netstack требует

различного ресурса

CPU

• В целом IP или

TCP/UDP требуют

большего CPU времени,

нежели Ethernet

фреймы, обработанные

только лишь Packet

Manager

• В зависимости от

инкапсуляции и

получателя, пакеты

могут быть переданы по

различным путям

Netstack


ARP & Adjacency Manager

• ARP отдельный процесс Netstack IP

• ARP регистрируется в PktMgr как L2 компонент

• ARP локальный для VDC процесс

• ARP процесс обслуживает работу ARP протокола

• ARP процесс также содержит всю специфическую для L3 интерфейса информацию (sh ip arp internal info int Ethernet <mod/port>)

• ARP обслуживает VIP зарегистрированные FHRP протоколами (HSRP, GLBP, VRRP)

• HSRP, GLBP, VRRP регистрируются в ARP process «слушают» ARP пакеты

• ARP пакеты посылаются напрямую в PktMgr по средствам MTS

• ARP Glean Adjacency: пакеты, получатель которых неизвестен, перенаправляются на CPU и приводят к началу “ARP resolution”


ARP (Address Resolution Protocol)

• ARP прочес выполняет все функции ARP (Decode & Encode)

n7k1-a11# show ip arp internal info interface ethernet 3/24

arp_if 0x81ac52c

Interface Ethernet3/24 context_name default and context_id 1

ttl 0 ARP rearp interval is 0 and Throttle timeoutis 300

ARP proxy is Disabled and Local proxy is Disabled

gratuitous_arp_timer_flag is Disabled

gratuitous_arp_request is Enabled

gratuitous_arp_update_cache is Enabled

FHRP proxy arp node is (nil)

n7k1-a11# show ip arp ethernet 3/24

Flags: * - Adjacencies learnt on non-active FHRP router

+ - Adjacencies synced via CFSoE

# - Adjacencies Throttled for Glean

D - Static Adjacencies attached to down interface

IP ARP Table

Total number of entries: 1

Address Age MAC Address Interface

10.5.2.2 00:12:48 0014.1bf6.4540 Ethernet3/24


Glean Throttle

• Glean Traffic

• Должен быть отправлен на CPU, чтобы инициировать ARP resolution

• Неизвестный получатель next-hop adjacency

• High bandwidth flows without Adjacency resolved may consume hardware rate-limiter resources (UDP flows or ECMP Path)

• Glean Throttle позволяет Control-Plane создать временную «DROP» запись до тез пор, пока ARP не будет завершен

• Drop Adjacency позволяет удалить все последующие записи на уровне ASIC, вместо того, чтобы перенаправлять на CPU

• Если же ARP так и не найден DROP Adjacency запись будет удалена, процесс повториться снова


Glean Throttle (Продолжение)

n7k1-a11(config)# hardware ip glean throttle timeout 330

• Glean Throttle включен по умолчанию

• Стандартное таймер 300 сек (300с-1800с)

• ‘show ip arp’ чтобы определить INCOMPLETE adjacency (т.е. те что Glean Throttle)

n7k1-a11# show ip arp vlan 1501

Flags: * - Adjacencies learnt on non-active FHRP router

+ - Adjacencies synced via CFSoE

# - Adjacencies Throttled for Glean

D - Static Adjacencies attached to down interface

IP ARP Table



10.66.2.10 00:00:25 0010.9400.0004 Vlan1501

10.66.2.11 00:00:25 0010.9400.0005 Vlan1501

10.66.2.23 00:00:25 0010.9400.0011 Vlan1501

10.66.2.24 00:00:25 0010.9400.0012 Vlan1501

10.66.2.150 00:00:15 INCOMPLETE Vlan1501 #

Glean Throttle

engaged for

10.66.2.150 in

VLAN1501


Glean Throttle (Продолжение)

• Временное Drop Adjacency для не разрешенных ARP программируется в ASIC

module-3# show forwarding ipv4 adjacency vlan 1501

IPv4 adjacency information

next-hop rewrite info interface

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

10.66.2.21 0010.9400.000f Vlan1501

10.66.2.22 0010.9400.0010 Vlan1501

10.66.2.23 0010.9400.0011 Vlan1501

10.66.2.24 0010.9400.0012 Vlan1501

10.66.2.150 unresolved Vlan1501

module-3# show forwarding internal trace v4-adj-history | grep 1501

Mon Feb 4 21:28:45 2013 Vlan1501 10.66.2.150 Destroy

Mon Feb 4 21:28:46 2013 Vlan1501 10.66.2.150 Create

Mon Feb 4 21:33:47 2013 Vlan1501 10.66.2.150 Update



Mon Feb 4 21:38:49 2013 Vlan1501 10.66.2.150 Update



Drop Adjacency vs. No

Adjacency which will cause FIB

to match Network Glean

Adjacency & Punt


Adjacency Manager (AM)

• Программирует /32 хост-записи в аппаратной части

• Все подключённые, L2 adjacent хосты имеют /32 запись

• Для того программирования записей в FIB, AM работает напрямую с процессами URIB/UFDM

• AM управляет next-hop adjacencies изученных в ARP, IGP, или статически сконфигурированных

• Управляет Adjacency SDB что позволяет восстановить записи при рестарте процесса

• Иначе говоря, можно рассматривать AM кака протокол маршрутизации для /32 хост маршрутов или next-hop смежностей


Клиенты Adjacency Manager

n7k1-a11# show system internal adjmgr client index

Protocol Name Alias UUID Index

bfd bfd 706 7

netstack Static 545 6

rpm rpm 305 5

IPv4 Static 268 4

arp arp 268 3

IP IP 545 2

icmpv6 icmpv6 270 1

• ARP записи добавляются в AM SDB (shared database)

• Затем AM напрямую информирует URIB и UFDM о необходимости

программирования /32 смежного маршрута в аппаратной части.

• AM регистрирует клиентов, которые могут сождавать смежности

• ARP самый основной клиент

• `show system internal adjmgr client index`


AM Installs Adjacency in uRIB

• AM публикует Add Adjacency запрос

• Далее AM информирует uRIB/uFDM о необходимости установить маршрут

n7k1-a11# show system internal adjmgr internal event-history events

8) Event:E_DEBUG, length:105, at 437243 usecs after Mon Feb 4 22:09:03 2013

[117] [3987]: Appending ADD 10.66.2.150 on Vlan1501 (TBL:1) AD 250 to rib buffer for Address Family :IPv4


[117] [4025]: Add 10.66.2.150 on Vlan1501 to rib work queue for afi: IPv4with work bit: 1


[117] [4025]: is_mct 0, entry_exists 0, iod 0x190 phy_iod 0x190


[117] [4025]: Got AM_ADD_ADJ_MSG on high_pri queue

n7k1-a11# show routing internal event-history add-route

Dumping: add-route

2013 Feb 4 22:09:03.437467 uRIB: "am": 10.66.2.150/32, new nh 10.66.2.150%Vlan1501, metric [250/0] route-type

unknown tag 0x00000000

2013 Feb 4 22:09:03.437433 uRIB: "am": 10.66.2.150/32, adding nh 10.66.2.150%Vlan1501, metric [250/0] route-type

unknown tag 0x00000000

AM Events

uRIB Add Route Event


uRIB and uFDM



• Netstack


• uRIB & uFDM


• L2FM & MTM




• VLAN Manager


• PIXM & PIXMc





uRIB & uFDM

• URIB – Unicast Routing Information Base

• Компонент управляющий SDB для всех L3 одноадресных маршрутов инсталлированных любыми протоколами маршрутизации

• VDC локальный процесс

• URIB клиенты:

• Протоколы марщрутизации (OSPF, EIGRP, BGP, etc)

• Netstack (клиент информирующий URIB о статических марзрутах)

• URIB Clients can be viewed with show routing clients

• uFDM (Unicast Forwarding Distribution Manager) is responsible for interacting with IPFIB process on each linecard to program hardware FIB, RPF & Adjacency (RIT/Rewrite)


uRIB & uFDM


uRIB

• Полученные от IGP маршруты инсталлируются в uRIB • Каждый протокол устанавливает валидный маршрут в собственный регион URIB памяти

• Далее IGP информирует URIB по средства MTS

• URIB then copies updated routes to its own protected region of shared memory

• URIB в последствии копирует маршрут в собственный защищённый регион общей (shared) памяти. Регион read-only для Netstack и других компонентов

• URIB operation is optimized to handle large updates (1000s of routes); would be much slower if updates were passed directly by MTS

• URIB оптимизирован для работы с большим кол-вом маршрутов, так традиционный механизм работы через MTS достаточно медлен

• URIB не создает/изменяет маршрутов. Все выполняется URIB клиентами – IGP/Netstack

• URIB в свою очередь регистрируется как клиент UFDM и использует UFDM API для передачи (программирования) данных в FIB / Forwarding Engines


OSPF uRIB Пример


uRIB Клиенты

n7k1-a11# show routing clients

CLIENT: ospf-10

index mask: 0x0000000000004000

epid: 374 MTS SAP: 320 MRU cache hits/misses: 10/1

Stale Time: 2100

Routing Instances:

VRF: "default" notifiers: self routes: 2, rnhs: 0, labels: 0

Messages received:

Register : 1 Notify-route-ack : 6 Convergence-notify: 1

Modify-route : 6

Messages sent:

Notify-route : 6 Modify-route-ack : 6

CLIENT: am

index mask: 0x0000000000000010

epid: 4516 MTS SAP: -1 MRU cache hits/misses: 19/9

Stale Time: 30

Routing Instances:

VRF: "default" routes: 1, rnhs: 0, labels: 0

Messages received:

Register : 1 Modify-route : 28

Messages sent:

• IGP регистрируются в uRIB как клиенты

• Клиенты используют MTS чтобы проинформировать о новых

маршрутах

• uRIB далее копирует информацию из SDB региона IGP в свою

собственную uRIB SDB


Статистика uRIB SDB

n7k1-a11# show routing memory statistics

uRIB SHRD MEM: allocated high-water maximum current #

bytes bytes bytes of allocs

uFDM buffers 0 1208960 2096840 0

redist buffers 0 64192 12582600 0

slbs, clt names 2376152 2376152 3145416 15

uRIB SLABS: allocated high-water elem size

elements elements bytes

clients 15 15 380

client-instance 20 20 144

table-instances 20 20 20

tables 3 3 356

routes 8027 8027 36

route-instances 8027 8027 32

next hops 8027 8027 80

change lst elms 8028 8028 32

recursive nhs 1 1 88

recursive nhinf 1 1 24

recursive nh paths 1 1 44

• Т.к. uRIB хранит всю IP routing информацию в свое собственной SDB, размеры

ее могут быть значительными

• May be needed to troubleshoot large routing scale or leaks in uRIB shared memory

• Как результат, данная статистика полезна при определении потенциальной

утески памяти или планировании масштабируемости


Пример: OSPF txlist в uRIB

n7k1-a11# show ip ospf internal txlist uRIB

ospf 10

System uptime 1w0d

SUP uptime 2 1w0d

Server up : L3VM|IFMGR|RPM|AM|CLIS|uRIB|U6RIB|IP|IPv6|SNMP

Server required : L3VM|IFMGR|RPM|AM|CLIS|uRIB|IP|SNMP

Server registered: L3VM|IFMGR|RPM|AM|CLIS|uRIB|IP|SNMP

Server optional : none

Early hello : OFF

Force write PSS: FALSE

OSPF mts pkt sap 324 tag 10

OSPF mts base sap 320 tag 10

OSPFv2->uRIB transmit list: version 0xbd7 <<< last OSPF update included:

2627: 10.5.2.0/24

2628: 100.201.100.0/24

2629: 10.5.1.0/24

2630: 10.66.37.0/24

2631: 10.67.37.0/24

2632: 10.66.38.0/24

.

.

3031: RIB marker

• OSPF создаёт/изменяет информацию о маршруте в OSPF сегменте

URIB общей памяти

• URIB переносит информацию в URIB Shared память

• Конечное решение (routing decision) делается на основе данных из URIB

shared памяти


Пример: OSPF Routes in uRIB

• OSPF марщруты в uRIB SDB

• Важно отметить, что такие маршруты известны программной части (Netstack), но это не гарантирует что они запрограммированы в аппаратной части hardware (FIB)

n7k1-a11# show ip route ospf-10 detail

IP Route Table for VRF "default"

'*' denotes best ucast next-hop

'**' denotes best mcast next-hop

'[x/y]' denotes [preference/metric]

'%<string>' in via output denotes VRF <string>

0.0.0.0/32, ubest/mbest: 1/0

*via Null0, [220/0], 1w4d, broadcast, discard

127.0.0.0/8, ubest/mbest: 1/0

*via Null0, [220/0], 1w4d, broadcast, discard

255.255.255.255/32, ubest/mbest: 1/0

*via sup-eth1, [0/0], 1w4d, broadcast

10.5.1.0/24, ubest/mbest: 1/0

*via 10.5.2.2, Eth3/24, [110/5], 1w4d, ospf-10, intra

10.99.1.1/32, ubest/mbest: 1/0


100.201.100.0/24, ubest/mbest: 1/0


192.168.66.0/24, ubest/mbest: 1/0



uFDM & IPFIB

• Основной задачей uFDM является перенос (программирование) марзрутов, смежностей, uRPF на всех линейных картах шасси

• uFDM процесс на супервизоре, который работает с IPFIB на каждом I/O модуле (uFDM VDC локальный процесс)

• IPFIB программирует локальный ASIC/forwarding engine FIB по средствам L3LU USD (Global Linecard Process)

• uRIB клиент uFDM и информирует о необходимых маршрутах по средствам API

• IPFIB коммуницирует с I/O модулем (через USD - User Space Driver) где собственно и программируется FIB / Adjacency

• Lamira USD

• Clipper L3LU USD


uFDM (Unicast Forwarding Distribution Manager)


uFDM FIB Download

• В случае установки новой LC, uFDM сообщает IPFIB о необходимости загрузить FIB базу на данный модуль.

• uFDM сам по себе не работает с маршрутами или смежностями, вместо этого привлекает uRIB сервис

n7k1-a11# show forwarding internal trace v4-pfx-history module 3

PREFIX 127.0.0.0/8 TABLE_ID 0xfffe

Time ha_handle next_obj next_obj_HH NH_cnt operation

Tue Feb 5 04:06:53 2013 0x80000002 V4 adj 0x43002 1 Create

PREFIX 10.5.2.0/24 TABLE_ID 0x1



.

.

.








End to End FIB Programming (OSPF Hardware FIB)

• OPSF пиринг сформирован и обмен LSA состоялся

• OPSF учит новые маршруты из LSA соседа

• OSPF процесс информирует uRIB относительно новых маршрутов

n7k1-a11# show ip ospf internal event-history event

OSPF events for Process "ospf-10"

2013 Feb 12 02:28:54.602424 ospf 10 [20333]: : Interface Ethernet3/24, (DROTHER), event NEIGHBORCHNG

2013 Feb 12 02:28:54.058212 ospf 10 [20333]: [20342]: Got a uRIB route notification message, xid 4294902448, count 4

2013 Feb 12 02:28:47.476181 ospf 10 [20333]: : Interface Ethernet3/24, (WAITING), event WAITTIMER

2013 Feb 12 02:28:17.706715 ospf 10 [20333]: : Interface Ethernet3/24, (WAITING), event NEIGHBORCHNG

2013 Feb 12 02:28:07.463325 ospf 10 [20333]: : Interface Ethernet3/24 ifDown --> WAITING

2013 Feb 12 02:28:07.463100 ospf 10 [20333]: [20342]: Incremented active if count 401

2013 Feb 12 02:28:07.462996 ospf 10 [20333]: : Interface Ethernet3/24, (DOWN), event INTERFACEUP

2013 Feb 12 02:28:07.462816 ospf 10 [20333]: : Received bandwidth change notification

2013 Feb 12 02:28:07.462811 ospf 10 [20333]: [20342]: Received notification for Ethernet3/24 (527), change mask 35,53

2013 Feb 12 02:28:07.462737 ospf 10 [20333]: [20342]: Got an L3 protocol state change notification

2013 Feb 12 02:28:07.243504 ospf 10 [20333]: [20342]: Received notification for Ethernet3/24 (527), change mask 36,82

2013 Feb 12 02:28:07.243419 ospf 10 [20333]: [20342]: Got an port parameter change notification

n7k1-a11# show ip ospf database

OSPF Router with ID (10.66.64.3) (Process ID 10 VRF default)

Network Link States (Area 0.0.0.0)

Link ID ADV Router Age Seq# Checksum

10.5.1.2 172.18.118.31 144 0x8000036f 0xb47c

10.5.2.2 172.18.118.31 144 0x8000031b 0x8051

100.201.100.2 192.168.66.1 1872 0x80000346 0x1c93


End to End FIB Programming (OSPF txlist to uRIB)

• OSPF копирует информацию из локальной памяти OSPF процесса в OSPF uRIB SDB

• После чего OSPF должен проинформировать uRIB об обновлении

n7k1-a11# show ip ospf internal txlist uRIB

ospf 10

System uptime 2w4d

SUP uptime 2 2w4d

Server up : L3VM|IFMGR|RPM|AM|CLIS|uRIB|U6RIB|IP|IPv6|SNMP

Server required : L3VM|IFMGR|RPM|AM|CLIS|uRIB|IP|SNMP

Server registered: L3VM|IFMGR|RPM|AM|CLIS|uRIB|IP|SNMP

Server optional : none

Early hello : OFF

Force write PSS: FALSE

OSPF mts pkt sap 324 tag 10

OSPF mts base sap 320 tag 10

OSPFv2->uRIB transmit list: version 0x172f

5531: 10.5.2.0/24

5532: 100.201.100.0/24

5533: 10.5.1.0/24

.

.

5935: RIB marker


n7k1-a11(config)# show ip ospf internal event-history rib

OSPF RIB events for Process "ospf-10"

2013 Feb 12 02:28:53.741783 ospf 10 [20333]: : Done sending routes to uRIB

2013 Feb 12 02:28:53.741779 ospf 10 [20333]: : Examined 405 OSPF routes

2013 Feb 12 02:28:53.737327 ospf 10 [20333]: : Route (mbest) does not have any next-hop

2013 Feb 12 02:28:53.737324 ospf 10 [20333]: : Path type changed from nopath to intra

2013 Feb 12 02:28:53.737320 ospf 10 [20333]: : Admin distance changed from 255 to 110

2013 Feb 12 02:28:53.737317 ospf 10 [20333]: : Mbest metric changed from 4294967295 to 5

2013 Feb 12 02:28:53.737312 ospf 10 [20333]: : Processing route 10.5.1.0/24 (mbest)

2013 Feb 12 02:28:53.737306 ospf 10 [20333]: : Done processing next-hops for 10.5.1.0/24

2013 Feb 12 02:28:53.737301 ospf 10 [20333]: : Path type changed from nopath to intra

2013 Feb 12 02:28:53.737297 ospf 10 [20333]: : Admin distance changed from 255 to 110

2013 Feb 12 02:28:53.737294 ospf 10 [20333]: : Ubest metric changed from 4294967295 to 5

2013 Feb 12 02:28:53.737289 ospf 10 [20333]: : Processing route 10.5.1.0/24 (ubest)

End to End FIB Programming (OSPF RIB Events)

• OSPF должен обработать и генирировать uRIB

апдейт и применят административную дистанцию

• uRIB messaging выполняется после того как

TXLIST «отправлен»


n7k1-a11# show ip route next-hop 10.5.2.2

IP Route Table for VRF "default"

'*' denotes best ucast next-hop

'**' denotes best mcast next-hop

'[x/y]' denotes [preference/metric]

'%<string>' in via output denotes VRF <string>

10.5.1.0/24, ubest/mbest: 1/0

*via 10.5.2.2, Eth3/24, [110/5], 00:02:06, ospf-10, intra

10.5.2.2/32, ubest/mbest: 1/0, attached

*via 10.5.2.2, Eth3/24, [250/0], 00:02:44, am

10.99.1.1/32, ubest/mbest: 1/0


100.201.100.0/24, ubest/mbest: 1/0


192.168.66.0/24, ubest/mbest: 1/0


End to End FIB Programming (uRIB)

n7k1-a11# show ip arp 10.5.2.2

IP ARP Table



10.5.2.2 00:12:06 0014.1bf6.4540 Ethernet3/24

n7k1-a11# show ip adjacency 10.5.2.2

IP Adjacency Table for VRF default


Address MAC Address Pref Source Interface

10.5.2.2 0014.1bf6.4540 50 arp Ethernet3/24

• uRIB программирует новые AM & OSPF марщруты в свою Shared Memory

• uRIB can then use the uFDM API to install newly updated prefixes in hardware

• uRIB displays client route provider and administrative distance

• В нашем примере 10.5.1.0/24 с next-hop 10.5.2.2

• ARP/AM outputs shown to observe L2 Rewrite information


• uRIB использует uFDM API to notify any route updates from uRIB clients

• uRIB stores updates in Shared Memory buffer and messages uFDM with the buffer index

• uFDM responds with “route-ack” on completion

n7k1-a11(config)# show routing internal event-history uFDM-summary

Dumping: uFDM-summary

2013 Feb 12 02:28:53.749129 uRIB: uFDM Buf 0x5a3059ec add rte 4 rnh 0 del rte 0 rnh 0 flgs 0x0 - Received route-ack

2013 Feb 12 02:28:53.743396 uRIB: uFDM Buf 0x5a3059ec add rte 4 rnh 0 del rte 0 rnh 0 flgs 0x0 - Sending









2013 Feb 12 02:26:52.311685 uRIB: uFDM Buf 0x5a35e2ac add rte 0 rnh 0 del rte 1 rnh 0 flgs 0x0 - Received route-ack

2013 Feb 12 02:26:52.310872 uRIB: uFDM Buf 0x5a340a6c add rte 0 rnh 0 del rte 1 rnh 0 flgs 0x0 - Received route-ack

2013 Feb 12 02:26:52.269738 uRIB: uFDM Buf 0x5a32322c add rte 0 rnh 0 del rte 1 rnh 0 flgs 0x0 - Received route-ack


2013 Feb 12 02:26:52.252651 uRIB: uFDM Buf 0x5a35e2ac add rte 0 rnh 0 del rte 1 rnh 0 flgs 0x0 - Sending

2013 Feb 12 02:26:52.251685 uRIB: uFDM Buf 0x5a340a6c add rte 0 rnh 0 del rte 1 rnh 0 flgs 0x0 - Sending

2013 Feb 12 02:26:52.250762 uRIB: uFDM Buf 0x5a32322c add rte 0 rnh 0 del rte 1 rnh 0 flgs 0x0 - Sending


End to End FIB Programming (uRIB To uFDM)


• uFDM Distributes AM, FIB, RPF Updates to IPFIB on each linecard in the vDC

• Acknowledgement is sent back to uRIB (Client) to confirm update

• Route-Ack from uFDM perspective

n7k1-a11# show system internal uFDM event-history debugs

1) Event:E_DEBUG, length:69, at 749128 usecs after Tue Feb 12 02:28:53 2013

[104] uFDM_route_send_ack(177):TRACE: sent route ack, xid: 0x5a3059ec


[104] uFDM_route_distribute(602):TRACE: v4_route_update: 2532 rt_count: 4, uRIB_xid: 0x5a3059ec,

fib_recp_count: 4


[104] uFDM_am_distribute(225):TRACE: distributed update to 4 LCs

End to End FIB Programming (uFDM)

Route Update

ACK to uRIB

Distribution from

uFDM to IPFIB


n7k1-a11# show system internal uFDM event-history msgs

4) Event:E_MTS_RX, length:60, at 749080 usecs after Tue Feb 12 02:28:53 2013

[RSP] Opc:MTS_OPC_uFDM_FIB_V4_ROUTE_UPDATE(74767), Id:0X089EAB39, Ret:SUCCESS

Src:0x00000702/200, Dst:0x00000501/195, Flags:None

HA_SEQNO:0X00000000, RRtoken:0x04848B11, Sync:UNKNOWN, Payloadsize:17

Payload:

0x0000: 00 00 01 49 80 00 00 04 00 04 01 ec 59 30 5a 01


[RSP] Opc:MTS_OPC_uFDM_FIB_V4_ROUTE_UPDATE(74767), Id:0X03843FD8, Ret:SUCCESS



Payload:

0x0000: 00 00 01 49 80 00 00 04 00 04 01 ec 59 30 5a 01


[RSP] Opc:MTS_OPC_uFDM_FIB_V4_ROUTE_UPDATE(74767), Id:0X0B9D6FBE, Ret:SUCCESS



Payload:

0x0000: 00 00 01 49 80 00 00 04 00 04 01 ec 59 30 5a 01


[RSP] Opc:MTS_OPC_uFDM_FIB_V4_ROUTE_UPDATE(74767), Id:0X0871322E, Ret:SUCCESS



Payload:

0x0000: 00 00 01 49 80 00 00 04 00 04 01 ec 59 30 5a 01

8) Event:E_MTS_TX, length:60, at 743704 usecs after Tue Feb 12 02:28:53 2013

[REQ] Opc:MTS_OPC_uFDM_FIB_V4_ROUTE_UPDATE(74767), Id:0X04848B11, Ret:SUCCESS

Src:0x00000501/195, Dst:0xFF000010/200, Flags:None


Payload:

0x0000: 00 00 01 49 38 01 00 00 00 04 00 ec 59 30 5a 01

End to End FIB Programming (uFDM Messaging)

SAP Source:

n7k1-a11# show system internal mts sup sap

195 description

uFDM SAP for control msgs

SAP Destination:

module-3# show system internal mts lc sap

200 description

ipfib SAP for ucast msgs

• uFDM must MTS message

IPFIB on each linecard via

MTS broadcast facility to

inform of FIB Route Update

• An MTS response can be

seen for each linecard that

received the broadcast

update

module-3# show system internal mts lc state

current

uptime: 7 days, 15 hours, 53 minutes, 26 seconds

mts ha state is line card (2)

my address is 0x302

active sup address is 0x501

Request Response Token: Correlates MTS Requests and Response(s)


module-3# show forwarding internal message counts

No of Download Done msgs : 2

No of Adjacency update msgs : 147

No of route update msgs processed : 604

No of v6route update msgs processed : 1

module-3# show system internal ipfib event-history msgs


[REQ] Opc:MTS_OPC_uFDM_FIB_V4_ROUTE_UPDATE(74767), Id:0X04848B11, Ret:SUCCESS

Src:0x00000501/195, Dst:0xFF000010/200, Flags:None


Payload:

0x0000: 00 00 01 49 38 01 00 00 00 04 00 ec 59 30 5a 01

End to End FIB Programming (IPFIB Messaging)

• IPFIB on module 3 logs the FIB Update MTS Message from uFDM

on Active Supervisor (Same message as previous slide ‘Event 8’)

• This MTS message will drive an update to the local FIB AVL tree

and subsequent hardware programming

• Additionally we can track the number of updates of various types

IPFIB receives from uFDM


n7k1-a11# show forwarding internal trace v4-pfx-history module 3

PREFIX 10.5.1.0/24 TABLE_ID 0x1


Tue Feb 12 02:26:51 2013 0x8000001f V4 adj 0x43007 1 Destroy

Tue Feb 12 02:28:52 2013 0x8000001f V4 adj 0x43007 1 Create

n7k1-a11# show forwarding internal trace v4-adj-history module 3

HH 0x43007

Time if NH operation

Tue Feb 12 02:26:51 2013 Eth3/24 10.5.2.2 Destroy

Tue Feb 12 02:28:14 2013 Eth3/24 10.5.2.2 Create

Tue Feb 12 02:28:14 2013 Eth3/24 10.5.2.2 Update

module-3# show forwarding ipv4 route platform module 3

Prefix 10.5.1.0/24, No of paths: 1, Update time: Tue Feb 12 02:28:52 2013

10.5.2.2 Ethernet3/24 DMAC: 0014.1bf6.4540

packets: 0 bytes: 0

HH:0x8000001f Flags:0x0 Holder:0x1 Next_obj_type:5

Prefix 10.5.2.0/24, No of paths: 1, Update time: Tue Feb 12 02:28:06 2013

Attached Ethernet3/24

packets: 0 bytes: 0

HH:0x80000016 Flags:0x9 Holder:0x1 Next_obj_type:5

module-3# show system internal forwarding route 10.5.1.0

Routes for table default/base

----+---------------------+----------+----------+------+-----------

Dev | Prefix | PfxIndex | AdjIndex | LIFB | LIF

----+---------------------+----------+----------+------+-----------

1 10.5.1.0/24 0x19004 0x43007 0 0x405c

module-3# show system internal forwarding adjacency entry 0x43007

Device: 1 Index: 0x43007 dmac: 0014.1bf6.4540 smac: 00ef.63e6.a7c1 e-vpn: 1

e-lif: 0x405c packets: 0 bytes: 549755813888

End to End FIB Programming (PI & PD FIB)

• Platform Dependent IPFIB

must manage hardware

specific structures such as

hardware table indexes

and device instances

• These outputs also display

the history of creates &

destroys for FIB route data

• These outputs show the

FIB state as seen by the

software FIB on the

module

• However, we don’t know

for sure what is in the

hardware FIB tables until

we check it directly


module-3# csl lamira show fib-tcam ipv4 instance 0x1 index 0x19004

FIB IPv4 TCAM entry for instance = 0x0

FIB IPv4 TCAM entry for index = 0x19004

addr = 10.5.1.0 mask = 255.255.255.0 VALID

vpn = 0x1 vpn_mask = 8191

module-3# csl lamira show fib-dram ipv4 ip instance 0x1 index 0x19004

module 3

FIB DRAM IPv4 entry for instance = 0x0

FIB DRAM IPv4 entry for index = 0x19004

entry_type = 0 no route = 0 router_ip = 0

default_entry = 0 adj_ptr = 0x43007 ls_count = 0x0

dest_as_num = 0x0 copy_to_cpu = 0 dgt_vld = 0

acos_qos_gid = 0x0 acos_vld = 0 qos_field_vld = 0

mpls_or_ip_tnl = 0 dgt_or_others = 0x0

module-3# csl lamira show adjacency instance 0x1 index 0x43007

Adjacency entry for instance = 0x0

Adjacency entry for index = 0x43007

dis_adj_stats = 1 dis_fwd_stats = 0 ad_trig = 0

l3_enable = 1 adj_valid = 1 ad_age = 2

adj_format = 0 rdt = 1 ignore_emut = 0

vpn = 0x1 egress_lif = 0x405c egress_lif_base = 0x0

ri = 3 top_sel = 0 zone_enforce = 0

filter_en = 0 frr_te = 0 index_sel = 0

tnl_encap = 0 rw_hint = 0x0 ttl_control = 4

module-3# csl lamira show rewrite-entry l2-rewrite instance 0x1 index

0x43007 module 3

RIT L2 entry for instance = 0x0

RIT L2 entry for index = 0x43007

trig = 0 D = 1 rmac = 0

smac = 1 dmac = 1 utos = 1

pipe_ttl = 0 l2_fwd = 0 ip_to_mac = 0

rnl = 1 rll = 1 ccc = 4

pv = 0 rc = 0 recirc_data = 0x0

dest_mac = 0014.1bf6.4540 src_mac = 18ef.63e6.a7c1

End to End FIB Programming (Lamira Tables)

• Using CSL commands we can

read the FIB & Adjacency

TCAM & DRAM memories

directly

• These are the values that are

actually used in the hardware

forwarding path

(EARL8/Lamira)

• Similar commands exist for F2

(Clipper)

• Different module types may

have multiple EARL8 instances

• FIB index resolves Adjacency

index

• Adjacency table stores RIT

(Rewrite) data


ABC# test forwarding inconsistency vrf 65500:300

Consistency check started.

ABC# sh forwarding inconsistency vrf 65500:300

IPV4 Consistency check : table_id(0x2a)

Execution time : 1306 ms ()

No inconsistent adjacencies.

Inconsistent routes:

1. slot(2), vrf(65500:300), prefix (10.11.32.0/19), Route inconsistent in FIB Hardware.






Вопрос №2

Хост 10.11.38.8 недоступен. Встроенный consistency-checker указывает на проблему в FIB HW. Сконфигурирован статический маршрут 10.11.32.0/19 через 10.11.35.7. Какой на ваш взгляд наиболее оперативный способ решить проблему?

a) SUP switchover `system switchover`

b) Последовательная перезагрузка модулей `poweroff module X`

c) `clear ip route vrf 65500:300 10.11.32.0/19`

d) Перезагрузить шасси `reload`

e) Создать аналогичный статический на Null0 `ip route a.b.c.d/x Null0`


L2FM & MTM



• Netstack


• uRIB & uFDM


• L2FM & MTM




• VLAN Manager


• PIXM & PIXMc





L2 Feature Manager (L2FM) & MAC Table Manager (MTM)

• L2FM это VDC локальный компонент для управления MAC адресами и связанными с ними таблицами

• Управляет утилитами/базами данных и тп для инсталляции/удаления/старения МАС адресов

• MTM это глобальный компонент линейной карты который связывает learn & aging события L2FM процессу и наоборот


L2FM & MAC Learning Terminology

• Local MAC Entry

– A MAC entry which points to a port behind the local switch

• Remote MAC Entry

– A MAC entry which points to a port behind a remote switch (vPC Peer Orphan Port)

• Ingress Learn

– MAC learning/update which takes place as the packet comes into a switch from the wire

• Egress Learn

– MAC learning/update which takes place as the packet is trying to egress (Flood-to-Fabric)

• MAC Lazy Learn or Install

– Software installing/overwriting entries in mac table because it could not be learnt by HW

for some reason

• MAC Owner Set

– Set of FEs where a mac is learnt or refreshed in hardware by packet flow

• MAC Target Set

– Set of FEs where a mac entry needs be to present based on learning scheme, owner set

and system configuration

• MAC Hints

– HW supplied bits in MAC table which give clues as to what should be the MAC target set


L2FM Debug MACDB

n7k1-a11# show system internal l2fm l2dbg macdb

Legend

------

Db: 0-MACDB, 1-GWMACDB, 2-SMACDB, 3-RMDB, 4-SECMACDB

Src: 0-UNKNOWN, 1-L2FM, 2-PEER, 3-LC, 4-HSRP

5-GLBP, 6-VRRP, 7-STP, 8-DOTX, 9-PSEC 10-CLI 11-PVLAN

12-ETHPM, 13-ALW_LRN, 14-Non_PI_MOD, 15-MCT_DOWN, 16 - SDB

17-OTV, 18-Deounce Timer, 19-AM, 20-PCM_DOWN, 21 - MCT_UP

Slot:0 based for LCS 19-MCEC 20-OTV/ORIB

VLAN: 1536 MAC: 0000.0c07.ac00

Time If Db Op Src Slot FE Local Remote

Thu Jan 24 17:13:32 2013 0x09010600 1 INSERT 4 0 15 1 0

Thu Jan 24 17:13:32 2013 0x09010600 1 INSERT 0 0 15 1 0

Thu Jan 24 17:13:33 2013 0x09010600 1 UPDATE 4 0 15 2 0

Thu Jan 24 17:13:54 2013 0x09010600 1 UPDATE 4 0 15 3 0

Thu Jan 24 17:14:45 2013 0x09010600 1 UPDATE 4 0 15 1 0

Thu Jan 24 17:14:46 2013 0x09010600 1 MAC SMLIST 2 0 15 0 0

Thu Jan 24 17:14:46 2013 0x09010600 1 UPDATE 2 0 15 1 3

Thu Jan 24 17:18:56 2013 0x09010600 1 UPDATE 4 0 15 2 3

• MACDB отображает текущее состояние MAC и историю о нем (программный

компонент)

• Отслеживает откуда (Slot/FE/Source) МАС адрес (Learn/Update/Flush) «пришел»

• Указывает был ли MAC инсталлирован из программной или аппаратной части

(HSRP или vPC)

• История МАС адреса это 10 последних событий

Use the Db and Src

Legends to identify

where the MAC was

installed from


A Closer Look at Debug MACDB

n7k1-a11# show mac address-table vlan 1500

Legend:

* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC

age - seconds since last seen,+ - primary entry using vPC Peer-Link,

(T) - True, (F) - False

VLAN MAC Address Type age Secure NTFY Ports/SWID.SSID.LID

---------+-----------------+--------+---------+------+----+------------------

G 1500 0000.0c07.ac00 static - F F vPC Peer-Link(R)

G 1500 0022.557a.2ac1 static - F F vPC Peer-Link(R)

G 1500 18ef.63e6.a7c1 static - F F sup-eth1(R)

* 1500 0010.9400.0004 dynamic 0 F F Po51

n7k1-a11# show system internal l2fm l2dbg macdb address 0010.9400.0004 vlan 1500

VLAN: 1500 MAC: 0010.9400.0004

Time If/swid Db Op Src Slot FE

Tue Jan 29 19:48:12 2013 0x16000032 0 DELETE 0 0 15

Tue Jan 29 19:48:14 2013 0x16000032 0 INSERT 3 2 0

Tue Jan 29 19:48:16 2013 0x16000032 0 FLUSH 0 0 15

Tue Jan 29 19:48:16 2013 0x16000032 0 DELETE 0 0 15

Tue Jan 29 19:48:18 2013 0x16000032 0 INSERT 3 2 0

Tue Jan 29 19:48:19 2013 0x7e000033 0 RESET_LL_UNDERWAY 2 0 15

Tue Jan 29 19:48:19 2013 0x16000032 0 FLUSH 0 0 15

Tue Jan 29 19:48:19 2013 0x16000032 0 DELETE 0 0 15

Tue Jan 29 19:48:21 2013 0x16000032 0 INSERT 3 2 0

Tue Jan 29 19:48:22 2013 0x7e000033 0 RESET_LL_UNDERWAY 2 0 15

Module 3 (Zero Based) Source = LC

n7k1-a11# show system internal pixm info | grep 0x16000032

Normal Po51 0x0a2a 0x16000032 0x00000000 0x00000002 1

Was this MAC entry learned

from Hardware?

First FE (Zero Based)


MTM (MAC Table Manager)

• MTM управляет MAC таблицами и рядом иных Layer-2 компонентов DC3 линейных карт

• Предоставляет PI интерфейс для L2FM и имеет свой PD интерфейс к различных FE архитектурах

• MTM это интерфейс между PI и PD модуля

• MTM работает с каждым L2FM процессом (отдельный для VDC) по средствам MTS


MAC Aging & L2FM

n7k1-a11# show system internal l2fm info agedb vlan_id 1898 VLAN MAC Address Ports Aged Bitmap State Timer ---------+-----------------+-----------+----------------+--------------+------ 1898 0010.9400.0004 Po51 1-2 PEND-REFRESH 25 1898 0010.9400.0005 Po51 1-2 PEND-REFRESH 27 1898 0010.9400.0007 Po51 1-2 PEND-REFRESH 20 1898 0010.9400.0009 Po51 1-2 PEND-REFRESH 20 1898 0010.9400.000a Po51 1-2 PEND-REFRESH 25 1898 0010.9400.000b Po51 1-2 PEND-REFRESH 26 1898 0010.9400.000c Po51 1-2 PEND-REFRESH 25 1898 0010.9400.000d Po51 1-2 PEND-REFRESH 21 1898 0010.9400.000e Po51 1-2 PEND-REFRESH 28 1898 0010.9400.000f Po51 1-2 PEND-REFRESH 27 1898 0010.9400.0011 Po51 1-2 PEND-REFRESH 22 1898 0010.9400.0012 Po51 1-2 PEND-REFRESH 20

• MAC записи, которые в скором времени должны быть удалены (flushed) из-за

старения отображаются в базе

• MAC не удалиться из hardware до тех пор пока L2FM сигнализирует

• МАС адрес находится в agedb некоторое время, на случай пропущенных

апднйтов


L2FM & Hardware Synchronization

• SUP и линейные карты имеют собственные MAC таблицы которые должны быть синхронизированы

• В тоже время, программные дефекты и перегруженность MTS очереди могут привести к рассинхронизации, лишая SUP возможности синхронизировать MAC адреса в дальнейшем (lazy learn)

• В дополнение, массивный MAC moves & flushes может привести к тому, что L2FM использует больше CPU и перегрузит MTS инфраструктуру • L2 петли

• Flapping MAC addresses

• Программные и аппаратные MAC таблицы не одно и тоже, и должны проверятся отдельно • show mac address table & show hardware mac address table x

• Software Table vs. Hardware L2 Forwarding TCAM

• Также можно использовать ‘show forwarding consistency l2 3’ для проверки согласованности между аппаратными и программными MAC таблицами


MAC Table Software vs Hardware (PI & Non-PI Examples)

n7k1-a11# show mac address-table vlan 1500 address 0010.9400.0004

Legend:

* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC

age - seconds since last seen,+ - primary entry using vPC Peer-Link,

(T) - True, (F) - False

VLAN MAC Address Type age Secure NTFY Ports/SWID.SSID.LID

---------+-----------------+--------+---------+------+----+------------------

* 1500 0010.9400.0004 dynamic 0 F F Po51

n7k1-a11# show hardware mac address-table 3 vlan 1500 address 0010.9400.0004

FE | Valid| PI| BD | MAC | Index| Stat| SW | Modi| Age| Tmr| GM| Sec| TR| NT| RM| RMA| Cap| Fld|Always

| | | | | | ic | | fied|Byte| Sel| | ure| AP| FY| | |TURE| | Learn

---+------+---+------+---------------+-------+-----+-----+-----+----+----+---+----+---+---+---+----+----+----+------

0 1 1 90 0010.9400.0004 0x00a2a 0 0x003 0 67 1 0 0 0 0 0 0 0 0 0

7k1-a11# show hardware mac address-table 4 vlan 1500 address 0010.9400.0004

FE | Valid| PI| BD | MAC | Index| Stat| SW | Modi| Age| Tmr| GM| Sec| TR| NT| RM| RMA| Cap| Fld|Always

| | | | | | ic | | fied|Byte| Sel| | ure| AP| FY| | |TURE| | Learn

---+------+---+------+---------------+-------+-----+-----+-----+----+----+---+----+---+---+---+----+----+----+------

0 1 0 90 0010.9400.0004 0x00a2a 0 0x003 0 29 1 0 0 0 0 0 0 0 0 0


2013 Jan 31 19:21:58 n7k1-a11-f2-fex %L2FM-4-L2FM_MAC_MOVE: Mac 0010.9400.0002 in vlan 100 has moved from Eth101/1/1 to Eth101/1/13



Monitoring MAC Moves

n7k1-a11-f2-fex(config)# logging level l2fm 4

n7k1-a11-f2-fex(config)# mac address-table notification mac-move

show system internal l2fm l2dbg macdb address 0010.9400.0002 vlan 100

VLAN: 100 MAC: 0010.9400.0002


Thu Jan 31 19:26:21 2013 0x1f640300 0 RESET_LL_UNDERWAY 2 0 15




Thu Jan 31 19:26:23 2013 0x1f640300 0 UPDATE 3 9 2

Thu Jan 31 19:26:23 2013 0x1f640300 0 UPDATE 3 9 2

Thu Jan 31 19:26:23 2013 0x1f640300 0 UPDATE 3 9 2




show system internal l2fm l2dbg macdb address 0010.9400.0002 vlan 100

VLAN: 100 MAC: 0010.9400.0002


Thu Jan 31 19:26:24 2013 0x1f640000 0 UPDATE 3 8 2

Thu Jan 31 19:26:24 2013 0x1f640000 0 UPDATE 3 8 2

Thu Jan 31 19:26:24 2013 0x1f640000 0 UPDATE 3 8 2

Thu Jan 31 19:26:24 2013 0x1f640000 0 UPDATE 3 8 2

Thu Jan 31 19:26:24 2013 0x1f640000 0 UPDATE 3 8 2






IfIndex Satellite Decode: Flapping

between 0000 (0) & 1100 (12)

which is zero based port index

MAC entry and Event records may roll over.

This may show MAC missing or specific

interface record missing. In the lab you may

want to bump these up:

test l2dbg macdb num-entries x

test l2dbg macdb num-records x


Troubleshooting Unicast Forwarding (SW tables)


Troubleshooting Unicast Forwarding (L2 HW tables)


Troubleshooting Unicast Forwarding (L3 HW tables)


Вопрос №3

О чем было бы интересно узнать на следующем вебинаре

a) VxLAN и его применение

b) Основы DFА

c) APIC / ACI / Insieme / Nexus 9000


Использованные термины

• KLM (Kernel Loadable Module)

• DBUS (Data Bus)

• LTL (Local Target Logic)

• FPOE (Fabric Port of Exit)

• VQI (Virtual Queue Index)

• VOQ (Virtual Output Queue)

• MTS (Message Transaction Service)

• SDB (Shared Database)

• Interface Index (Ifindex)

• IOD (Interface Ordinal Identifier)

• FE, L2LU, L3LU (Forwarding Engine / L2 Logical Unit / L3 Logical Unit)

• PD/PI (Platform Dependent or Independent)

• VDC Local vs. Global Components (VDC Local are not VDC aware while Global components are potentially VDC aware)

• In-band Leaking & Punting

• GID (Grant Identification)

• LDI (Local Destination Index used by Arbiter to identify destination port)

Отправьте свой вопрос сейчас!

Используйте панель Q&A, чтобы задать вопрос. Эксперты ответят на Ваши вопросы.

Получить дополнительную информацию, а также задать вопросы эксперту в рамках данной темы Вы можете на странице, доступной по ссылке:

https://supportforums.cisco.com/community/russian/expert-corner

Вы можете получить видеозапись данного семинара и текст сессии Q&A в течении ближайших 5 дней по следующей ссылке

https://supportforums.cisco.com/community/russian/expert-corner/webcast




https://supportforums.cisco.com/community/netpro/ask-the-expert/webcasts





Вебинар на русском языке

Тема: Внутренняя архитектура IOS-XE: Средства траблшутинга предачи трафика на ASR1k и ISR4400

в среду, 22 апреля, в 12.00 мск Присоединяйтесь к эксперту Cisco

Олегу Типисову

Во время презентации эксперт Cisco TAC Олег Типисов

рассмотрит некоторые особенности аппаратной

архитектуры платформ ASR1k и ISR4400/ISR4300, а также

какое выражение эти особенности нашли в архитектуре

операционной системы IOS-XE и встроенных в IOS-XE

средствах диагностики.


https://supportforms.cisco.com/community/russian

http://www.facebook.com/CiscoSupportCommunity

http://twitter.com/#!/cisco_support

http://www.youtube.com/user/ciscosupportchannel

https://plus.google.com/110418616513822966153?prsrc=3#110418616513822966

153/posts

http://itunes.apple.com/us/app/cisco-technical-support/id398104252?mt=8

https://play.google.com/store/apps/details?id=com.cisco.swtg_android

http://www.linkedin.com/groups/CSC-Cisco-Support-Community-3210019

Newsletter Subscription: https://tools.cisco.com/gdrp/coiga/showsurvey.do?surveyCode=589&keyCode=146298_2&PH

YSICAL%20FULFILLMENT%20Y/N=NO&SUBSCRIPTION%20CENTER=YES



http://twitter.com/#!/cisco_support














https://tools.cisco.com/gdrp/coiga/showsurvey.do?surveyCode=589&keyCode=146298_2&PHYSICAL FULFILLMENT Y/N=NO&SUBSCRIPTION CENTER=YES

https://tools.cisco.com/gdrp/coiga/showsurvey.do?surveyCode=589&keyCode=146298_2&PHYSICAL FULFILLMENT Y/N=NO&SUBSCRIPTION CENTER=YES


• Русском https://supportforums.cisco.com/community/russian

• Испанском https://supportforums.cisco.com/community/5591/comunidad-de-

soporte-de-cisco-en-espanol

• Португальском

https://supportforums.cisco.com/community/5141/comunidade-de-suporte-

cisco-em-portugues

• Японском http://www.csc-china.com.cn/

https://supportforums.cisco.com/community/russian

https://supportforums.cisco.com/community/russian

https://supportforums.cisco.com/community/5591/comunidad-de-soporte-de-cisco-en-espanol














https://supportforums.cisco.com/community/5141/comunidade-de-suporte-cisco-em-portugues












http://www.csc-china.com.cn/




Спасибо за Ваше время

Пожалуйста, участвуйте в опросе

nexus 7000 – архитектура передачи данных. Поиск и...

Technology

cisco andor

netstack cisco confidential

troubleshooting nexus

nxos netstack netstack

ssh netstack

mac addresses

packet processing path

series switches brkdct