I already read this document before. It does not answer to the question, it only explain how control-plane traffic is transported and handled over the VSL link. But my question concerns Fast-Hello link or BFD link, not VSL link. And the paragraphs related to "unified control-plane" and "distributed data-plane" do not help either: my question concerns "hardware processing architecture" and a specific case of "forUS/fromUS traffic" (not data-plane traffic) which is: the VSLP fast-hello session and messages (and L3 BFD also).
... View more
In VSS documentation, we can see that there are few events affecting the "catalyst 6500 CPU" (Sup2T MSFC CPU) that could cause the loss (or the flapping) of the VSL link:
• High CPU utilization can trigger a VSLP hello hold-timer timeout, which results in the removal of all the VSL links from the VSL EtherChannel. • The effects of system watchdog timer failures are similar to high CPU utilization. These might render the VSL EtherChannel non-operational. "
To protect against "Dual Active Scenario" (DAS), it is recommended to implement several "DAS detection methods" like: ePAGP, VSLP fast-hello or L3 BFD.
My question is: to make a "DAS detection method" efficient, this method should not be affected by the same "CPU issues" which could lead to VSL link loss (high CPU utilization, effect of watchdog timers…) => so, my question is:
- Which hardware component is responsible for handling “VSLP_fast_hello messages”: is it DFC of the line-card (DFC hardware offload) ? Is it PFC of the supervisor-card (centralized PFC hardware offload) ? Or is it MSFC of the supervisor-card (centralized MSFC CPU processing) ?
- Same question for BFD message (BFD echo mode used for DAS detection)
Thank in advance,
... View more