3

I have two routers that I'm setting up currently and they will be feeding my network of servers with a private AS number provided by the datacentre.

What I want to do is provide both a VRRP failover default route for servers on the network, and also ensure that routing out and inbound will always be preferred via one path and only take the other path if and only if the primary preferred path is down. i.e. a MASTER/BACKUP setup.

I have the VRRP stuff sorted out already. But my knowledge of BGP is very basic.

Let me draw some ascii art of the topology to make it a bit clearer.

ISPA (AS 1)               ISPB (AS 1)
  |                         |
  |                         |
  R1 --- P2P (ethernet) --- R2 (AS65007)
  |                         |
  +------- LAN (ipoib) -----+  

The ISP A & B routers are the remote routers at the same datacentre. Lets assume they have AS 1. And also I have a private AS which is 65007

Now lets state it again. I want traffic from AS 1 to always reach me via R1 and never R2 unless the R1 path to ISP A is offline.

Lets assume ISPA and R1 have IP's 10.1.1.1/30 & 10.1.1.2/30 respectively. And assume ISPB and R2 have IP's 10.1.1.5/30 & 10.1.1.6/30 respectively.

Also assume the network range I want to advertise is 192.168.1.0/25.

My current config with no biased routing currently works and looks like this:

For R1 (R2 being almost the same).

ip prefix-list Net:Out seq 5 permit 192.168.1.0/25

router bgp 65007
  bgp router-id 10.1.1.2
  redistribute connected route-map Redist:BGP
  neighbor 10.1.1.1 remote-as 558
  neighbor 10.1.1.1 description Net
  neighbor 10.1.1.1 soft-reconfiguration inbound
  neighbor 10.1.1.1 prefix-list Net:Out out

route-map Redist:BGP permit 10
match ip address prefix-list Net:Out

** Which also has a problem because R1 doesn't know that it can reach R2 at 10.1.1.6. There is no IBGP. How do I fix that in the above? **

I'm told I can bias the data in several ways. From my NOC I'm told I can use localpref and prepend my AS on the backup router.

If I understood this right it would look something like the following. Where R1 config would remain the same. Is this the correct syntax for quagga and would this work?

ip prefix-list Net:Out seq 5 permit 192.168.1.0/25

router bgp 65007
  bgp router-id 10.1.1.6
  redistribute connected route-map Redist:BGP
  neighbor 10.1.1.5 remote-as 558
  neighbor 10.1.1.5 route-map Net:In in
  neighbor 10.1.1.5 description Net
  neighbor 10.1.1.5 soft-reconfiguration inbound
  neighbor 10.1.1.5 prefix-list Net:Out out

route-map Redist:BGP permit 10
match ip address prefix-list Net:Out
set as-path prepend 65007 65007

route-map Net:In
set local-preference 10

However, when I described my problem to an acquaintance who works in the networking field, he told me that there is still a good chance that data will still come down through R2 side from the ISP and described another way to do it. He said I could also use MED if the ISP will accept it. Or alternatively, because both lines come from the same ISP he said to me that routing is very deterministic and will always select the most specialized path. So he suggested on my primary R1 router I instead advertised two networks. i.e. two /26's. Is this correct and would it work. Should I perhaps combine both methods?

ip prefix-list Net:Out seq 5 permit 192.168.1.0/26
ip prefix-list Net:Out seq 10 permit 192.168.1.64/26

router bgp 65007
  bgp router-id 10.1.1.2
  redistribute connected route-map Redist:BGP
  neighbor 10.1.1.1 remote-as 558
  neighbor 10.1.1.1 route-map in Net:In
  neighbor 10.1.1.1 description Net
  neighbor 10.1.1.1 soft-reconfiguration inbound
  neighbor 10.1.1.1 prefix-list Net:Out out

route-map Redist:BGP permit 10
match ip address prefix-list Net:Out

So what would you BGP experts suggest to me, and how do I determine after making the necessary changes that it is in fact working.


Update: The subnet method directly above didn't work. I guess my provider is rejecting anything smaller than a 25. Confirmed when I tried it on one router. show ip bgp didn't propagate the route at all. Perhaps I can use MED? would that be any better than the first method?

2

There are several ways to accomplish what you want, and yes, prepending your own AS to the routes (prefixes) you advertise to ISP, along with setting a LOCAL_PREF to the ones you (will) re-advertise internally is a good point.

Basically, you need to:

  1. Make the prefixes (routes) you advertise through R1 preferred for ISPA (influencing inbound path).
  2. Make all the prefixes you receive from ISPA at R1 (including the default route - assuming you don't use any static routes) preferred for your internal network (influencing outbound path). A small note here: because end-hosts use default gateway and don't perform routing, it's up to VRRP to drive packets from end-hosts to R1, but anyway you can obtain that even if packets arrive at R2, R2 will forward those packets to R1 rather than ISPB.

For point 1, MED, AS prepending, communities, etc. are possible metrics (ie. BGP attributes) to tune, but the one that will work without modification from the remote side is AS prepending most probably (eg. MED might require a statement like "bgp always-compare-med" in the ISP router maybe, depending by their config).

For point 2, LOCAL_PREF and WEIGHT can be used (also communities and other techniques we don't care about in this case). WEIGHT is Cisco proprietary (but Quagga uses it), also it is not included in the BGP updates (locally significant), so I'd go for LOCAL_PREF (that works with iBGP you don't have yet, though).

Having said that, in order to reach netdc.com as you want, one option is:

#
# R1
#
router bgp 65007
  bgp router-id 10.1.1.2
  network 192.168.1.0/25
  neighbor 10.1.1.1 remote-as 558
  neighbor 10.1.1.1 description Net
  neighbor 10.1.1.1 soft-reconfiguration inbound
  neighbor 10.1.1.1 route-map Net:In in
  neighbor 10.1.1.1 route-map Net:Out out

  neighbor iBGP_peers peer-group
  neighbor iBGP_peers remote-as 65007
  neighbor iBGP_peers password $whatyouwant
  neighbor iBGP_peers update-source $IP  #The interface in the common subnet 192.168.1.0/25, otherwise you need an internal routing protocol (IGP) also
  neighbor iBGP_peers next-hop-self      # Otherwise you need to advertise the p2p network between you and ISP

  neighbor $IP_R2_in_192.168.1.0 peer-group iBGP_peers
  neighbor $IP_R2_in_192.168.1.0 description R2

ip prefix-list local-allocations seq 10 permit 192.168.1.0/25

route-map Net:In
  description allow everything

route-map Net:Out
  description announce allocated routes sourced from our AS only (avoid to become a transit AS)
  match ip address prefix-list local-allocations

#
# R2
#
router bgp 65007
  bgp router-id 10.1.1.6
  network 192.168.1.0/25
  neighbor 10.1.1.5 remote-as 558
  neighbor 10.1.1.5 description Net
  neighbor 10.1.1.5 soft-reconfiguration inbound
  neighbor 10.1.1.5 route-map Net:In_backup in
  neighbor 10.1.1.5 route-map Net:Out_backup out

  neighbor iBGP_peers peer-group
  neighbor iBGP_peers remote-as 65007
  neighbor iBGP_peers password $whatyouwant
  neighbor iBGP_peers update-source $IP  #The interface in the common subnet 192.168.1.0/25, otherwise you need an internal routing protocol (IGP) also
  neighbor iBGP_peers next-hop-self      # Otherwise you need to advertise the p2p network between you and ISP

  neighbor $IP_R1_in_192.168.1.0 peer-group iBGP_peers
  neighbor $IP_R1_in_192.168.1.0 description R1

ip prefix-list local-allocations seq 10 permit 192.168.1.0/25

route-map Net:In_backup
  description iBGP will de-prefer all the prefixes
  set local-preference 10

route-map Net:Out_backup
  description announce allocated routes sourced from our AS only
  match ip address prefix-list local-allocations
  set as-path prepend 65007 65007 65007

On a side note, redistribution is bad if you can avoid it. Use 'network' command to advertise your prefix (in Quagga you don't need the subnet in your RIB contrary to Cisco, even better than).

2
  • Is the question answered?
    – matteo
    Sep 11 '15 at 13:41
  • Did you have the chance to give it a try?
    – matteo
    Sep 24 '15 at 12:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.