[c-nsp] BFD and no ip redirects ?

Discussion:

selamat pagi

2010-12-07 11:53:38 UTC

According to Ciscos config guide, *no ip redirects* need to be configured
for BFD

I'm trying to understand why this is required.

thanks, keti
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Chris Evans

2010-12-07 13:16:54 UTC

Permalink

The command is used so that on the far end the packet doesnt get punted to
the cpu. The line card processes the return.

Post by selamat pagi
According to Ciscos config guide, *no ip redirects* need to be configured
for BFD
I'm trying to understand why this is required.
thanks, keti
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Pete Lumbis

2010-12-07 14:23:14 UTC

Permalink

BFD is only processed on the linecard on the GSR. For the 6500/7600
this is still done on the CPU, but it is done in the interrupt
context, making it preferred over something like Fast Hellos which is
handled as part of normal process scheduling.

I think there are plans to make BFD distributed on the 6500/7600
platforms, but it's not here yet.

-Pete

Post by Chris Evans
The command is used so that on the far end the packet doesnt get punted to
the cpu. The line card processes the return.

_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Chris Evans

2010-12-07 14:53:02 UTC

Permalink

Correct it doesnt do distributed bfd but the command allows the line cards
to do the packet return processing when in async mode. Cant remember if this
is dfc only modules or not...

Post by Pete Lumbis
BFD is only processed on the linecard on the GSR. For the 6500/7600
this is still done on the CPU, but it is done in the interrupt
context, making it preferred over something like Fast Hellos which is
handled as part of normal process scheduling.
I think there are plans to make BFD distributed on the 6500/7600
platforms, but it's not here yet.
-Pete

Post by Chris Evans
The command is used so that on the far end the packet doesnt get punted to
the cpu. The line card processes the return.

_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Benjamin Lovell

2010-12-07 15:20:35 UTC

Permalink

No either way in async mode it will be done in hardware as long as IP redirects have been turned off. DFC or no is jut where the lookup is done.

-Ben

Post by Chris Evans
Correct it doesnt do distributed bfd but the command allows the line cards
to do the packet return processing when in async mode. Cant remember if this
is dfc only modules or not...

Post by Chris Evans
The command is used so that on the far end the packet doesnt get punted

Post by Pete Lumbis

Post by Chris Evans
the cpu. The line card processes the return.

Post by selamat pagi
According to Ciscos config guide, *no ip redirects* need to be

configured

Post by Pete Lumbis

Post by Chris Evans

Post by selamat pagi
for BFD
I'm trying to understand why this is required.
thanks, keti
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Phil Mayers

2010-12-07 15:28:41 UTC

Permalink

Post by Benjamin Lovell
No either way in async mode it will be done in hardware as long as IP
redirects have been turned off. DFC or no is jut where the lookup is
done.

I don't understand this statement.

Are you saying that the 6500 does BFD in hardware?
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Benjamin Lovell

2010-12-07 16:40:51 UTC

Permalink

Some other around I sure know it better than me. BFD has two modes. I tend to forget/mix up the terms but they are generally as so..

1) I send you hellos, you send me hellos. Similar enough to any route protocol method that you get the idea.
2) I send a packet to you that is addressed back to myself. When you get the packet you do a forwarding lookup and just send it right back to me. This is done in hardware with one caveat, you must turn off redirects else packet will be punts as routing lookup says egress same interface you came in on.

As you can see in scenario two far side will "process" BFD packets in hardware as it really does not care/know it was a BFD packet.

I have a dubious opinion of the usefulness as you are really only proving the forwarding of the ONE IP forwarding entry that leads back to your connected IP, but that's the idea anyway.

-Ben

Post by Phil Mayers

Post by Benjamin Lovell
No either way in async mode it will be done in hardware as long as IP
redirects have been turned off. DFC or no is jut where the lookup is
done.

I don't understand this statement.
Are you saying that the 6500 does BFD in hardware?
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Gert Doering

2010-12-07 22:09:16 UTC

Permalink

hi,

Post by Benjamin Lovell
I have a dubious opinion of the usefulness as you are really only
proving the forwarding of the ONE IP forwarding entry that leads
back to your connected IP, but that's the idea anyway.

Well, it proves that the path is working end-to-end (which helps a lot
in todays "everything is ethernet, but no useful error signalling"
environments) and that there is at least a compatible IP configuration
on the remote interface (same network or unnumbered with a proper route
back).

Of course this is not a complete self-test of the remote machine, but
that would be somewhat expensive to do every 10ms :-)

gert

--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany ***@greenie.muc.de
fax: +49-89-35655025 ***@net.informatik.tu-muenchen.de

Benjamin Lovell

2010-12-09 22:17:43 UTC

Permalink

Agree but so does BFD in echo mode but echo also proves that the IP punt path to the CPU is working. So not that I see no value in BFD but I do not see any additional value of this mode over echo.

-Ben

Post by Gert Doering
hi,

Well, it proves that the path is working end-to-end (which helps a lot
in todays "everything is ethernet, but no useful error signalling"
environments) and that there is at least a compatible IP configuration
on the remote interface (same network or unnumbered with a proper route
back).
Of course this is not a complete self-test of the remote machine, but
that would be somewhat expensive to do every 10ms :-)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/

Roger Wiklund

2010-12-07 13:22:29 UTC

Permalink

Before using BFD echo mode, you must disable the sending of Internet
Control Message Protocol (ICMP) redirect messages by entering the no
ip redirects command, in order to avoid high CPU utilization.

from ietf draft:

BFD Echo packets MUST be transmitted in UDP packets with destination
UDP port 3785 in an IPv4 packet. The setting of the UDP source port
is outside the scope of this specification. The destination address
MUST be chosen in such a way as to cause the remote system to forward
the packet back to the local system. The source address MUST be
chosen in such a way as to preclude the remote system from generating
ICMP Redirect messages. In particular, the source address SHOULD NOT
be part of the subnet bound to the interface over which the BFD Echo
packet is being transmitted, unless it is known by other means that
the remote system will not send Redirects.
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Oliver Boehmer (oboehmer)

2010-12-07 13:26:21 UTC

Permalink

Post by selamat pagi
According to Ciscos config guide, *no ip redirects* need to be

configured

Post by selamat pagi
for BFD
I'm trying to understand why this is required.

BFD echo packets are sent from a node towards its neighbor with its own
link address as IP destination addresses (so the neighbor sends it
back), which would trigger an ICMP redirect on the neighbor, and we
don't want/need this. I acutally don't think BFD breaks if you have ip
redirects enabled on the peer..

oli

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/