Skip to content
Jan 9 / Greg

FIB did not return source address – ASR9K or IOS-XR

I saw this recently when helping to troubleshoot an issue “FIB did not return source address”. This was for a BGP route destination when I tried to traceroute it. The route was in the routing table, so why couldn’t I trace to it?

In BGP when I learn a route via eBGP(external BGP) the next-hop address for this route, by default, will always be the address of the eBGP neighbor. Even if I’m 5 iBGP routers away, it will always be the IP of the eBGP neighbor. This network build for this particular issue wasn’t so complicated.

Network diagram:
(eBGP ISP1) — (eBGP Border1 iBGP) — (iBGP Border2)

Border2 was trying to send traffic to destinations sourced from ISP1, but they were getting the FIB error. This is because while Border2 had the destinations learned via eBGP and were valid, they didn’t have a valid route to ISP1’s IP address(the one it was peered with and sourcing the routes from). They had a static null route for the ISP1 IP address on Border2 which means every route destined for ISP1 was getting thrown in the bit bucket.

Resolution is to ensure all routers have a valid route in their local table to reach the IP address that ISP1 is sourcing routes from. I generally do this by redistributing connected routes into OSPF. You could also explore something like “Next-hop self” which overrides the default behavior, but I prefer keeping it default so I can easily see where routes are sourced from.

Good luck and happy routing.

Leave a Comment