0

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 Mesh Diagram

BGP setup:

  • PAT1 and PAT2 each have a eBGP session with ISP1 and ISP2 to announce 199.192.100.0/24.
  • LB1 announces 199.192.100.0/28 over iBGP sessions to PAT1 and PAT2
  • PAT1 and PAT2 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 and PAT2 originate a default route to LB1 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?

Andy Shinn
  • 4,211
  • 8
  • 40
  • 55
  • 1
    Post sanitized BGP protocol configuration snippets from both routers. – SpacemanSpiff Jan 29 '13 at 18:51
  • Unfortunately, I continued working on this issue and have it working correctly now and my BGP config changed so much in between the working model and this question that it isn't worth posting. But your right, I could have given a lot more config information, even if it was sanitized. – Andy Shinn Jan 31 '13 at 03:42

1 Answers1

0

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.

Aaron
  • 2,968
  • 1
  • 23
  • 36
  • Unfortunately, I've made a couple changes since this question and now I am not able to replicate the issue. What it boiled down to was missing gateway IP on PAT1 and PAT2 (199.192.100.1 and 199.192.100.2 respectively) so that OSPF would actually take the path and distribute it. I was trying to do this without have to statically assign any gateways. But Juniper implementation of OSPF does not allow a session when the networks on the peering interfaces do not match (subnet mismtach error). I've accepted your answer based mostly on the fact that, yes, I was overthinking this way too much :) – Andy Shinn Jan 31 '13 at 03:40
  • Nobody allows a OSPF neighbor to come up if the two interfaces are in different networks If you expected that portion to work, some replanting needs to be done. – Aaron Jan 31 '13 at 04:37