f the route announce is coming from the BGP neighbor you need to verify if the next-hop indicated for this route is itself reached by the router, if by recursion the router do not resolve how to go to the next-hop then the announced route will be not available. THe bgp sender must set the next-hop with a reachable address, sometimes this is achieved by the sender using the next-hop-self in the export policy, but it is possible other situations where the next-hop is unreachable. If the sender is using a specific address for all the next-hops for all the announced routes you will need just a static route pointing to the gateway for his next-hop. If the BGP session for some reasons goes down then the default route will apply and the redundancy through ISP1 will work fine. Best Regards, Ricardo On Thu, May 27, 2010 at 9:38 PM, Ken Gilmour <ken.gilmour@gmail.com> wrote:
Wow, very fast responses, Thanks Larry Sheldon and Ricardo Tavares!
On 27 May 2010 18:07, Ricardo Tavares <curupas@gmail.com> wrote:
Not sure if I correctly undestand you but default route its the route that the packet must follow if it do not have a specific route for the destination, so, if the next-hop for the source IP (3.3.3.3) is not in the route table then the packet will follow the default route (ISP1).
Yes I believe that would be the default if the session was initiated on the inside, but if it comes from outside on a particular interface which is not the default route, why would the router then send the packet out another interface? Should the device not route session-based traffic according to where it originated?
So, this behavior will be correct if next-hop for 3.3.3.0/24 is not installed. Just for troubleshooting purpose install a static route like:
set routing-options static route 3.3.3.0/24 next-hop <the-correct-gateway-address> (ISP2)
Yes sir, this works, but when you change the static route to point 0.0.0.0/0 to the next hop on the virtual router for the particular interface (ISP2) it starts going over the interface for ISP1 again. I also set qualified-next-hop for ISP2 in the main routing table to no avail.
If this works fine then verify the route table, are you using BGP to receive such routing info? If you are not filtering the update maybe the sender is. Verify the received routes using the "show route protocol bgp receive-protocol bgp x.x.x.x" (x.x.x.x is the bgp neighbor)
Yes sir, I have also gone to the extent of deactivating BGP and using only static routes.
Thanks for your help!
Regards,
Ken