I am trying to accommodate for a link failure between LB1
(a Linux machine running Quagga) and either PAT1
or PAT2
(Juniper MX80 routers). The following diagram is a canonical version of my network layout:
BGP setup:
PAT1
andPAT2
each have a eBGP session withISP1
andISP2
to announce199.192.100.0/24
.LB1
announces199.192.100.0/28
over iBGP sessions toPAT1
andPAT2
PAT1
andPAT2
have a iBGP session between each other to redistribute external learned routes (so that either router can get back to the internet should a ISP link fail)PAT1
andPAT2
originate a default route toLB1
to get back out to the Internet- Internet traffic is currently coming in over
ISP2
When I sever the link between PAT2
and LB1
, traffic dies at PAT2
because PAT1
does not announce a backup path to 199.192.100.0/28
. I was under the impression that PAT1
would be redistributing the 199.192.100.0/28
route to PAT2
so that it could use it in case of a failure. But it appears that this is not how iBGP works by design.
What is a good way to overcome the iBGP limitation where it does not announce learned iBGP routes?
Best Answer
I think you're overthinking this design and going about it the wrong way.
PAT1, PAT2, and LB1 should all iBGP peer with one another. LB1 should originate 199.192.100.0/28 PAT1 and PAT2 should both originate 199.192.100.0/24 Do not put any filters on any of the ibgp sessions.
What IGP (OSPF?) are you running between these routers? The default route PAT1 and PAT2 are originating should come from the IGP, not from iBGP.
The problem isn't that PAT1 isn't announcing a backup path to the /28, the problem is that PAT2 doesn't believe it can get to LB1 via PAT1. What does a 'show ip route' on PAT2 for LB1 look like when the link between PAT2 and LB1 is down? If you take down that link, the iBGP session between LB1 and PAT2 should still stay up, if it goes down, again, that points to an IGP problem.