cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
818
Views
10
Helpful
7
Replies
jorg_b
Beginner

BGP redundancy question

I have a somewhat complex BGP question regarding multi-homed redundancy.  

Here is my layout

          [INTERNET]

          |                  |

     [ISP 1]         [ISP 2]

         |                   |

     [Loc 1]--------[Loc 2]

 

I'm getting internet from 2 different backbone providers. Both backbone providers only send me a default route via BGP.

Loc 1 and Loc 2 are also connected to each other via a metro ethernet link and (ibgp). I'm also using ospf for some internal stuff. I'm currently advertising multiple /20 from both locations. I'm advertising the same /20s from both locations. I currently use "aggregate-address xxx.xxx.xxx.xxx 255.255.240.0 summary-only" to announce our address space to the upstream backbone providers in conjunction with "ip route xxx.xxxx.xxx.xxx 255.255.240.0 Null0" to make sure I "feed" the /20 into BGP. So, both providers currently only see 8 (/20) announcements. Inbound traffic is fairly balanced between the 2 backbone providers. So, traffic for Loc 2 might be coming in via ISP 1 and travels via the metro ethernet link to Loc 1 and vise versa.

The problem is that when my metro ethernet connection goes down between Loc 1 and Loc 2, my network is pretty much dead, as inbound traffic for both locations is relying on the connection between Loc 1 and Loc 2 to be up. I think the problem is that both my BGP announcements are seen as /20's on the internet and when the link between Loc 1 and Loc 2 goes down, there are no specific announcements indicating what IP addresses are served by what location.

The reason I'm doing the announcements the way I'm doing them right now is because I was under the impression that one should not announce small IP blocks (such as /30, /29, etc) to the Internet via BGP.

Can you please give me a hint on how this is done these days.

 

Thanks a million

 

 

7 REPLIES 7
Richard Burts
Hall of Fame Guru

You are certainly correct that advertising small blocks such as /29 or /30 is not good (and would not work). And advertising summarized addresses is a good thing. So using the aggregate-address is a beneficial way to configure BGP.

 

Without knowing more about your environment it is difficult to give you good advice. I have a couple of thoughts to share and if we learn more about your situation we may be able to give better suggestions.

 

My first thought is that configuring the static route to null 0 for the /20 may be part of the problem. As long as at least one constituent route is present in the routing table BGP will advertise the summary. So you do not really need the static route. And with the static route your routers will advertise the summary - whether they can really get to it or not. So my first suggestion is to remove the static routes to null 0 for the summaries.

 

We do not know how the routes are distributed in your network. But if we were lucky enough that all of the constituent routes of the first summary were found connected to site A, if all of the constituent routes for the second summary were found connected to site B, and if both sites advertise their routes to each other using OSPF then using the summary address on both BGP routers would work pretty well. As long as the metro Ethernet is working then both routers know about all routes and both routers can advertise the summaries using the aggregate-address command. But if the metro Ethernet goes down then site A withdraws the site B routes from its table and its BGP withdraws that summary route. Now the only advertisement into the Internet for those routes is coming from the router that can reach them.

 

That is how many organizations do it these days.

 

HTH

 

Rick 

HTH

Rick

Rick,

Thank you for taking the time to respond to my message. I would like to provide a more detailed response to some of the points you made.

By design I allocate my /20's to either location 1 or Location 2. I don't mix and match, as it becomes inefficient and messy when is comes to doing ospf area ranges (ospf aggregation announcements across areas). I use ospf to route traffic internally and beyond the edge routers.However, each edge router also has iBGP peering with the other routers. My network layout above is very much simplified in order to keep the focus on the initial question/issue I have.

Your suggestion to remove the null routes is a step towards my solution. Currently I'm NOT using " redistribute ospf" within my BGP config, but by removing the Null0 routes for each /20, I will need to feed the routes into BGP so that it can advertise the IP space for each location via the "aggregate-address" method. Of course, I will filter out all the IP's that should not be advertised to the upstream providers. Does that sound reasonable to you?

Here is my bgp and ospf config on Loc 1 (slightly modified for public viewing):

router ospf 1
 router-id 10.255.0.1
 log-adjacency-changes
 area 0 authentication message-digest
 redistribute connected
 redistribute static subnets
 passive-interface TenGigabitEthernet1/49
 network 123.xxx.xxx.xxx 0.0.0.255 area 0
 network 234.xxx.xxx.xxx 0.0.0.255 area 0
 default-information originate metric 100
!
router bgp 12345
 no synchronization
 bgp router-id 10.255.0.1
 bgp log-neighbor-changes
 network 128.xxx.xxx.xxx mask 255.255.240.0
 network 144.xxx.xxx.xxx mask 255.255.240.0
 aggregate-address 128.xxx.xxx.xxx 255.255.240.0 summary-only
 aggregate-address 144.xxx.xxx.xxx 255.255.240.0 summary-only
 redistribute static
 neighbor 123.xxx.xxx.2 remote-as 12345
 neighbor 123.xxx.xxx.2 next-hop-self
 neighbor 123.xxx.xxx.2 default-originate
 neighbor 123.xxx.xxx.4 remote-as 12345
 neighbor 123.xxx.xxx.4 next-hop-self
 neighbor 123.xxx.xxx.4 default-originate
 neighbor 70.xxx.xxx.1 remote-as 6789
 neighbor 70.xxx.xxx.1 send-community
 neighbor 70.xxx.xxx.1 soft-reconfiguration inbound
 neighbor 70.xxx.xxx.1 prefix-list IPSPACE out
 neighbor 70.xxx.xxx.1 route-map EBGP-PRIMARY-IN in
 neighbor 70.xxx.xxx.1 route-map EBGP-PRIMARY-OUT out
 neighbor 70.xxx.xxx.1 filter-list 80 out
 no auto-summary

 

The bgp and ospf config at Loc 2 looks very similar (with other IP's of course)

 

Your feed back is appreciated.

 

Thanks

 

 

Thanks for the additional information. I agree that separating the /20 so that it is contained at a single site is a good design. It not only will help your OSPF it will be good for your BGP as well.

 

I do not see a need to redistribute from OSPF into BGP. As long as there is a network statement for the route in BGP and the route is present in the routing table (advertised by OSPF should do that) then BGP will advertise the route and not need redistribution.

 

Also I do not see a need to have network statements for the /20 networks. Unless there is an entry in the IP routing table with that prefix and that mask they do not work. And as I have said I believe that having the routes for those prefixes to null 0 is causing problems. Instead I would suggest that you put network statements for the constituent routes that make up the /20 and then use the aggregate-address to advertise the summary and not the individual routes.

 

I could see one solution where each of your BGP routers has network statements only for the networks/subnets at its location (and not advertise the networks/subnets from the other site). This would take care of the issue when the metro Ethernet is not working. And it has the benefit of reducing the amount of traffic traversing your metro Ethernet. It does reduce the redundancy and failover capability, so I can assume that you might not want to use this alternative. But it is one to consider.

 

I can also see a solution in which you would have in the BGP configuration network statements for all the constituent routes of the /20 (for both sites) and with the aggregate-address commands. Then as long as the metro Ethernet is working and OSPF is advertising all routes then both sites advertise all routes. And if there is a problem with metro Ethernet then OSPF does not advertise the routes to the other site and the site withdraws the BGP advertisement for routes that it an not get to. It seems to me that this would be a very attractive alternative for you.

 

HTH

 

Rick

HTH

Rick

Rick,

 

Thanks again for your answer. I think the solution I'm looking for is your suggestion, "[...] have in the BGP configuration network statements for all the constituent routes of the /20 (for both sites) and with the aggregate-address commands."

The final question I have regarding this is related to the network statements and the aggregate-address statements.

Since I break down my /20s (at each location) into anything from a /30 to a /24, do you suggest to have a network statement for each address block showing in the routing table (which would be quite a few network statement), or summarize it somehow, as I thought I'm currently doing? The same question applies to the aggregate-address statement... since the sum of the many /30, /29, /28... /24 address blocks will equal a /20, should I continue to aggregate announce the /20 to by upstream provider?

 

Thanks

 

You ask two interesting questions and I believe that the best answer to the first one is the famous "it depends". In terms of how many network statements you should configure - If you value completeness and full accuracy then you should have a network statement for every network (including the /30s). On the other hand you may want to have network statements for some/most/all of the LAN addresses but not for any transit networks in your networks. Remember that with aggregate-address as long as at least one of the constituent networks is present in the routing table then BGP will advertise the summary.  So it is a bit of a balancing act to determine how many network statements you need. If there are some LAN addresses that are of high importance in your network then I would certainly have a network statement for each of them. If there are some addresses that it would not have negative impact if the Internet could not get to them then I would not have network statements for them.

 

The answer to your second question about continuing to use the aggregate address command sort of depends on how you want things to work. My personal preference would be to use the aggregate-address commands to summarize what you advertise to the Internet. The essence of the issue is what do you want to happen when some network inside your Enterprise network is not available. With aggregate-address the Internet will continue to send packets for that network to you and your edge router (or some router inside your network) will need to determine that the destination is not reachable. If you do not use aggregate-address then you will advertise many networks to the Internet (and contribute to the bloat that increases the size of the Internet routing table) but now the remote network can determine whether the destination network is reachable.

 

HTH

 

Rick

HTH

Rick

Hello

Possible utilise the bgp "backdoor" feature

Is it feasible to make the link between your LOC sites the primary path via an IGP (ospf, eigrp) and then apply the backdoor command to make the routes over bgp a secondary path.

 

As you are advertising each site local routes anyway  when you apply she backdoor feature your local site metric coming in over the bgp will have an metric of 200 which will be a higher metric then ospf and it should provide the resiliency and optimal path between the two sites.

 

res

Paul



kind regards
Paul

Please rate and mark posts accordingly if you have found any of the information provided useful.
It will hopefully assist others with similar issues in the future

Hi,

as you are saying "By design I allocate my /20's to either location 1 or Location 2. ", why don't you simply advertise 2x /21 from the location where the particular /20 is allocated and /20 from the second site?

This way the traffic from the Internet would be delivered to the right site as long as its Internet connection would be Up. As the most specific prefix wins, /21 would always beat the less specific /20 advertised from the second site.

In a case the Internet connection would fail on the first site, the /20 advertised from the second site would be used and your OSPF would deliver the traffic to the first site via the internal line.

 

You can create those two /21 using the aggregate-address ... summary-only command, e.g.

Let's say your /20 is 128.xxx.0.0/20. (i.e., 128.xxx.0.0 - 128.xxx.15.255 IP range)

So on the primary router you would need to use

aggregate-address 128.xxx.0.0 255.255.248.0 summary-only
aggregate-address 128.xxx.8.xxx 255.255.248.0 summary-only
 

while on the secondary router

aggregate-address 128.xxx.0.xxx 255.255.240.0 summary-only

 

Best regards,

Milan