Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

MPLS with IPsec VPN Backup

Hi All,

I would like to find out about best practice to build network around dynamic routing protocol to enable redundancy between all sites.

I have a network layout in attachment.

 

Assumptions:

  • Site1 is main site with all internal services running in it (of the 192.168.1.0 network). 
  • Site1 is a main IPSEC hub for all IPSEC only sites (Site3) 
  • Site2 is a example of site that uses high speed, low latency MPLS network to connect to Site1 and other sites.
  • Site2 uses IPsec based vpn tunnel as a failover
  • Site2, Site3 are configured with EIGRP as a STUB
  • Site1 is configured as EIGRP and it is transition network
  • Site3 whenever connecting to Site2 has to use MPLS network
  • Site3 uses secondary IPSEC tunnel as a backup
  • MPLS_CORE is under control of ISP

Questions

  • What is the best practice to allow redistribution between BGP routers (S1_MPLS and S2_MPLS) and EIGRP AS?
  • What is the best practice to setup MPLS network to be primary route for all sources?
  • How to force S1_MAIN router to use MPLS uplink for Site2 subnets ? Does it require disabling split-horizon on interface ? Can I force it to always route traffic for these subnets via S1_Core without setting up route-maps ?
  • Is EIGRP right choice for that type of network ? 

 

Regards

 

M

4 REPLIES

Hi, guite a difficult task as

Hi,

 

guite a difficult task as usually with mutual redistribution involved.

EIGRP stub feature is a good option here, but I'll be even more careful here, i.e., I'd suggest to tag any redistributed prefixes and configure route-maps denying these tagged prefixes from redistribution back to the original protocol (possibly on other site).

 

Let's look at particular sites starting with the easiest one:

Site3) All you need here is to configure the IPSec main circuit to be preferred.

So to conifigure a better EIGRP metric for the prefixes received/advertised over the main circuit compared to the prefixes received/advertised over the backup circuit.

 

Site2) You need to configure the S2_Core1 router to prefer any prefix received form the S2_MPLS router over the same prefix received from S2_DSL router.

Again, manipulating the EIGRP metric of prefixes received from S2_MPLS can make it.

(Another possibility would be running both BGP and EIGRP on S2_Core but I don't suppose so?)

Plus make sure you are advertising only the local prefixes to both S2_MPLS and S2_DSL.

 

Site1) Is the most complicated. As this is the site where mutual BGP/EIGRP redistribution is done.

So you need a router to run both protocols and control the mutual redistribution.

One possibility would be to run eBGP between S1_MPLS and S1_Core1 and EIGRP between S1_Core1 and S1_Main and S1_Backup.

You should configure a route-map on S1_Core1 tagging the prefixes redistributed from BGP to EIGRP by tag B.

And deny EIGRP prefixes received with tag B from being redistributed back to BGP on S1_Core1.

 

Now: Any prefix received from S1_MPLS would beat the same prefix received from EIGRP due to  better eBGP AD.

In a case some prefix would be received via EIGRP only (from Site 3 or Site 2 with MPLS line failed), it would get to the RIB on S1_Core1 and be redistributed to BGP on it.

In a case of Site2 MPLS line recovered, you would receive the same prefix via BGP on S1_Core1.

But it would be in RIB already and use BGP weight attribute 32768 (redistributed on this router originally). Which would be bad.

So you need a route-map to set weight=0 (and local preference = 50 for sure) while redistribuing EIGRP to BGP on S1_Core1 to fix this situation.

On the other hand: Should the prefix redistributed originally from S1_Core1 to BGP be received via BGP again from S1_MPLS, it would be dropped as having S1_Core1 AS number already within the AS_PATH. That's another reason why I suggest eBGP between S1_MPLS and S1_Core1.

 

I hope my ideas helped you a little.

In a case of any questions, just raise them here!

 

Best regards,

Milan

 

 

 

 

 

 

 

 

New Member

Hi Milan,Thanks for these

Hi Milan,

Thanks for these answers.

I will continue on Site1 setup as other sites are pretty straight forward. 

The problem i'm trying to overcome is if traffic from Site3 to Site2 lands on router S1_MAIN. S1_MAIN due to "split horizon" rule on EIGRP should only have route pointing via IPSEC tunnel which is not what i want. MPLS network should be always preferred route for all source subnets. 

S1_MAIN might not know that there is better path via S1_MPLS (if S1_MPLS received route advertisement and due to split horizon did not advertise it back) and hence S1_MAIN will route traffic via IPSEC_BACKUP link (much slower with higher latency).

I have two ideas how to force (in most simple way) S1_MAIN and S1_BACKUP to always route all type of traffic via S1_CORE (as eventually S1_MPLS, S1_MAIN and S1_BACKUP wont be sharing broadcast domain - these will be connected via dedicated routed interfaces on S1_CORE1 L3 switch). 

1st. Via route summarization - S1_MAIN and S1_BACKUP will advertise summary address of 192.168.0.0/16 to S1_CORE. S1_CORE will have more detailed prefixes learned from S1_MPLS and will always pick these. That will solve issue with split horizon and S1_CORE will be able to advertise 192.168.x.0/24 routes to S1_MAIN and S1_BACKUP as only 192.168.0.0/16 has been learned from them. 

2nd. Via route maps. I could setup on each IPSEC tunnel route map requesting that S1_CORE1 will be next hop when routing to 192.168.x.0 subnets. S1_CORE will have all information about current state of network and should make most precise routing decision. 

 

Also i think that I will solve BGP-> Eigrp redistribution by using Static routes (doubled going via 2 interfaces for redundancy) and redistributing only these to MPLS network and then redistributing from BGP to EIGRP with relevant metrics. 

 

How does this sound ? Is that over complicated solution ? 

 

Hi Michal,I don't understand

Hi Michal,

I don't understand your problem described by

"

The problem i'm trying to overcome is if traffic from Site3 to Site2 lands on router S1_MAIN. S1_MAIN due to "split horizon" rule on EIGRP should only have route pointing via IPSEC tunnel which is not what i want. MPLS network should be always preferred route for all source subnets.

S1_MAIN might not know that there is better path via S1_MPLS (if S1_MPLS received route advertisement and due to split horizon did not advertise it back) and hence S1_MAIN will route traffic via IPSEC_BACKUP link (much slower with higher latency)."

 

Are you talking about the route for Site3 received on S1_MPLS router?

I don't know where exactly you are redistributing BGP/EIGRP in your topology. On S1_Core1 or S1_MPLS?

Let's say you are redistributing on S1_MPLS:

S1_MPLS is receiving routes for Site3 via BGP and also via EIGRP (from S1_Main which had received it via IPSec tunnel).

As the eBGP AD is better than EIGRP one, S1_MPLS puts the BGP route to his RIB and redistributes it to EIGRP. So it advertises it to EIGRP with some good metric.

S1_Main then receives the route via EIGRP from S1_MPLS with a better metric than the original prefix received via IPSec.

So it puts the new prefix to his RIB and starts to forward packest with Site3 destination address via S1_MPLS.

No EIGRP Split Horizon is applied, as the better route was not received on the same interface as the original IPSec one.

 

Alos note: The Split Horizon rule is only about advertising the prefix back out from the interface it was received, not ignoring it!

See http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/16406-eigrp-toc.html#splithorizon

for more details.

 

BR,

Milan

 

 

 

 

 

New Member

One more questions.How in

One more questions.

How in details EIGRP split horizon works?

I know general rule that it does not advertise same subnet back to a interface it learned from.

Is that purely based on subnet/mask or is there more in it ? I came to a point where i designed network as I described below and EIGRP advertised same subnet between two hosts (back and forth). 

269
Views
0
Helpful
4
Replies
CreatePlease login to create content