How do I configure iBGP on my border routers?

Hi,

We run VRRP on the inside of our Juniper border routers, and I've had a static 0.0.0.0/0 254 route pointing from each router to the other in the case that the BGP sessions on the primary router go down (say the fibre gets cut), but the router itself stays up (meaning it's still the VRRP master and receiving the traffic with nowhere to go).

This lets traffic flow into the vrrp master (router 0) and then through to router 1, then out to the world.

This works ok.

I would like to swap this to iBGP instead of static routes, but because our upstream advertise us a 0.0.0.0/0 route in the bgp feed (along with lots of other routes) its causing problems.

Basically router 1 receives the bgp feed containing it's 0.0.0.0 - 111.x.x.x route which comes in at a 100 local pref, and it also has a 0.0.0.0 - 192.168.1.2 (local interface)  254 pref configured locally.

Local config:
 route 0.0.0.0/0 {
            next-hop 192.168.1.2;
            preference 254;
        }

Open in new window



I then use iBGP to advertise the 0.0.0.0 route to router0, but because the upstream's default route is a lower pref, it will advertise that (0.0.0.0 111.x.x.x), instead of my intended one (0.0.0.0 - 192.168.1.2).

This means that if router0 drops its bgp session with the upstream, it will have a route from router1 saying 0.0.0.0 111.x.x.x which is useless as it can't reach that 111.x.x.x due to the connection drop.


I've tired this:
policy-statement exportdefault {
        term default {
            from {
                route-filter 0.0.0.0/0 exact {
                    next-hop 192.168.1.2;
                }
            }
            then accept;
        }
        term else {
            then reject;
        }
    }

Open in new window


But that doesn't work.

How do I force router1 to send 0.0.0.0 192.168.1.2 instead of 0.0.0.0 111.x.x.x.x?


Thanks,
LVL 1
nwteamAsked:
Who is Participating?
 
harbor235Connect With a Mentor Commented:

The issue you are describing is not a problem, it is the way BGP was designed. BGP was never designed that way because it's an EGP, an IGP was designed to perform that routing function. Now I agree that next-hop-self is a way to extend BGP to provide that functionality, I guess I am a old school and like segmentation between my EGP and IGP, they really do provide unique services within your routing domain.

If you add the external link that you peer with into ospf as well as sending default (make it passive), then you do not have to worry about next-hop-self. Next-hop-self is a way to correct the problem as Mike states but I would not do it that way.

harbor235 ;}



0
 
harbor235Commented:


You should be sending default via your IGP not via iBGP.

harbor235 ;}
0
 
mikebernhardtCommented:
That is a very common problem. In Cisco, there's a neighbor command which is "next-hop-self." This tells the router to advertise itself as the next hop to an iBGP neighbor which is not the default, as you discovered.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.