What is one pain-in-the-butt thing with wireless links connected to a Ethernet port on a Cisco router?
You don’t know when the wireless link goes down?
Since Ethernet technology does not provide for end-to-end connectivity checks, like ATM OAM F5, Frame-Relay EEK, or PPP LCP Keepalive, you need a similar method to know when the wireless link or the remote site is unreachable.
There are varies workarounds, eg using IP SLA monitor, or using BGP with reduced timers. A better solution is to use Bidirectional Forwarding Detection (BFD), to quickly identify the failing wireless VLANs and route your retraffic quickly and efficiently.
BFD keepalives are generated and processed by the linecards, which allows transmitting at a much higher rate compared to normal ‘IGP’ hello messages that are usually generated by the RP (Route-Processor).
The BFD protocol is designed solely as an agent for other applications requiring fast forwarding path failure-detection. But BFD is by no means a new feature. Up to quite recently, it has lacked the stability one would expect from such a genius protocol.
As of October 2008, the implementation of BFD on Cisco routers is still somewhat sporadic and depends on the hardware platform you’re using and the software that the platform is running. All modern routing protocols (OSPF, IS-IS, EIGRP and BGP), as well as Hot Standby Router Protocol (HSRP), work with BFD. Some platforms can also use BFD to track the status of static routes.
The hardware support is sketchier: high-end routers (including ASR) running specialized IOS releases (eg, the 12.2 SRC release) support almost anything you might need in the core of your network. Integrated Service Routers (1800 through 3800) however support BFD on Ethernet interfaces, but not on serial links.
BFD support now also extends to MPLS TE’s, whereby BFD-triggered Fast Reroute allows for faster, and more consistent FRR Link Protection and FRR Node Protection.