cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1496
Views
0
Helpful
4
Replies

MPLS with IPsec VPN Backup

Michal Trembacz
Level 1
Level 1

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 4

milan.kulik
Level 10
Level 10

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

 

 

 

 

 

 

 

 

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

 

 

 

 

 

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). 

Review Cisco Networking products for a $25 gift card