瓶颈突破

不想整天在工作中迷失,天天想一想
正文

ISSU from several examples

(2011-04-25 21:17:43) 下一个
EgressQ
=============================================
V1 forwarding
V1 software gets terminated by sysmgr
V2 software gets spawned (recovers state from checkpointing like a regular restart)
V2 Config gets replayed
     platfrom-mgr replays the create interfaces, egress use info of checkpointed V1
     qos_ea replays the config, same mapping as in V1
End of Config
     EgressQ cleans "dirty" resources (v1 resources unclaimed by v2 config)
NSF Stop
     IMDR sends NSF Stop event
     EgressQ stops sharq forwarding, ack to IMDR
NSF Update
     Do nothing
NSF Start
     Flush the v2 config to HW, going through the RSM to realign the data
     clear stats, and re-enable the output
IMDR Done
     Egressq clears its state (no longer in IMDR mode)


FGID
=============================================
MRIB is ISSU-Aware.
Even if all routes have been re-learned, and new FGIDs allocated, the LC hardware keeps forwarding for a while using the old forwarding information. At one point, when all LCs are ready, traffic is stopped, the new microcode is installed and the new HW tables are programmed, and traffic is resumed, this time using the new FGIDs. Only after that (when the ISSU is complete) may the old FGIDs be deleted. Actual condition to delete old FGIDs is "NSR Timeout and ISSU Complete Event".

Punting Packets to Keep Source Aliveness
=============================================
ATT complained about punting packets to keep source aliveness. LC processes punted packets and send notification to RP.
Solution is to use per-route stats, which is expensive.
CSCsm21902 "Get source liveness state through stats


Impactful MDR for Metro
=============================================

Design Notes
=============================================
iMDR clients
    NSF client group                  - for drivers involved in the NSF Replay Sequence
    Forward client group            - for those involved in forwarding download state
    config client group               - for the clients to report configure update done

iMDR start  - all the sysmgr/iMDR registered clients perform impactful MDR specific action
iMDR reload - the process restart initialization after MDR to startena()
Config update - config playback update for the local, remote and shared plane config onto the platform drivers' RSM
Forwarding Download - download the forwarding data to PSE driver's RSM/Cache where the critical routes need to be in place at least
NSF replay - a sequence to replay the updated drivers's RSM/Cache and resume the traffic







[ 打印 ]
阅读 ()评论 (1)
评论
目前还没有任何评论
登录后才可评论.