[c-nsp] BFD on ME3600/ME3800/7600s

[Adam Vitkovsky]

> James Bensley
> Sent: Tuesday, May 31, 2016 9:50 AM
>
> On 28 May 2016 at 10:31, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>
> wrote:
> > Alright then so indeed nodes participating in echo mode have to do more
> work as nodes participating in non-echo mode. That's why assume it
> performs slower (comparing performance of both modes in SW).
> >
> > To do list of one of the nodes in non-echo mode:
> > Tx at a given rate.
> > Reset dead timer if hello from remote node received.
> >
> > To do list of one of the nodes in non-echo mode:
> > Tx at a given rate.
> > Reset dead timer if own hello received.
>
> >>   > Loop partner's hellos at a given rate.   <<
>
> This last item is a bit of a misnomer.
>
> This isn't an extra feature the CPU has to do. The CPU on has to perform the
> first two action, which are the same (more or less) in both echo and non-
> echo modes.
>
> In echo mode the sending host sets its own MAC as the source MAC and the
> receiving node MAC as the destination MAC within the Ethernet headers. In
> the IP headers the source and destination IP are both the sending node's IP.
> So the receiving node receives the BFD packet because it has the destination
> MAC, but it see's the destination IP is the sending node, so this should be
> forwarded in hardware like any other L3 packet, so in echo mode the remote
> node that received the echo frame is unaware it is forwarding BFD packets
> for the node that send the echo packet. So there is no additional action for
> nodes running echo mode.
>
Aah good point, I see now where you're coming from.
So the packet is looped via the forwarding path and it doesn't have to be punted to the BDF control plane.

In echo mode I'd expect some increase in Rx times because now the hello has to travel up and down the link (so twice the propagation delay) and also at the remote/looping end it depends on how BFD packets are scheduled.


Ok looking at your initial post and the increase is huge (seconds).
But it's the max Tx that's affected (in addition to Rx) so I guess that's because the BFD messages are now generated in the CPU so if you do "sh run" or bgp does it's thing it can negatively impact generation of BFD messages.
Why the Rx has this huge jump as well? -I don't know, maybe it's correlated it with other Rx values rather than particular Tx value? And since Tx is shifted it shifts the Rx as well?
Since it's seconds I doubt this is a problem with buffers at the looping end.


adam






        Adam Vitkovsky
        IP Engineer

T:      0333 006 5936
E:      Adam.Vitkovsky at gamma.co.uk
W:      www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.