cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
13911
Views
25
Helpful
21
Replies

Ask the VIP: Network Path Redundancy Design

ciscomoderator
Community Manager
Community Manager

Marwan Al-shawi

Cisco Support Community Ask the VIP conversation.

Learn about Network Path Redundancy Design from Cisco Designated VIP Marwan Al-shawi.

Marwan Al-shawi is a senior network engineer and technical consultant with Dimension Data Australia, a Cisco Global alliance partner that is part of the largest telecommunications company in Japan and Asia. He has also worked as a network architect with IBM Australia, global technology services, and other Cisco partners and IT integrators. He holds a master of science degree in internetworking from the University of Technology, Sydney, and holds Cisco certifications including CCNP, CCSP, CCDP, Cisco Unified Computing Technology Support Specialist, and CCDE (written).    

Remember to use the rating system to let Marwan know if you have received an adequate response. 

 

Marwan might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Network Infrastructure sub-community discussion forum shortly after the event. This event lasts through May 4 , 2012. Visit this forum often to view responses to your questions and the questions of other community members.

21 Replies 21

Hi

so your problem is when the HSRP track go to down state lets say when there is latency for example but the actual DMVPN mGRE tunnel is still up and in this case it keeps advertising your LAN to the hub via the " pervious active" HSRP Router, while outgoing traffic using HSRP will go out using the second HSRP router "current active HSRP"

if this is the case then one simple way that you can use to fix it is by using Cisco Embedded Even Manager EEM

where EEM can watch the state of your track used in HSRP ( in the primary/active router ) and when its gose to the down state it can add an offset list to the EIGRP configuration to increase the advertised LAN route metric

then when the track state comes back up, another EEM applet will remove the command to put it back to the original config

this might require some seconds to converge

bellow an example of config you can try on the active/primary HSRP router only

assuming in this example the track being used is "track 10" and eigrp AS is "100", DMVPN tunnel interface is " tunnel1" and the LAN subnet is 10.10.1.0/24:

and make sure that the eigrp metric value below to be something higher than the secondary hsrp router value with the distribute list you mentioned about,this to make the former hsrp active eigrp routes less preferred by the hub site during failover situation

ip prefix-list 1 seq 5 permit 10.10.1.0/24

event manager applet EIGRP-1

event track 10 state down

action 1.0 cli command "en"

action 1.1 cli command "config t"

action 1.2 cli command "router eigrp 100"

action 1.3 cli command "offset-list 1 out 100 tunnel 1"

event manager applet EIGRP-2

event track 10 state up

action 1.0 cli command "en"

action 1.1 cli command "config t"

action 1.2 cli command "router eigrp 100"

action 1.3 cli command "no offset-list 1 out 100 tunnel 1"

please note this is just an example, it is highly recommended that you test it before using it in a production network

EEM is a very powerful IOS feature where you can automate a lot of network failover and add additional level of network topology awareness to the failover for unconventional requirements such as your case above

http://www.cisco.com/en/US/docs/ios/netmgmt/configuration/guide/nm_eem_policy_cli.html

hope this help

Hello Marwan,

My question involves failover routing over an IPSEC/GRE Tunnel.  We currently have 20 spoke sites connecting to one central datacenter over MPLS, all via t1 or bundled T1s.  Every local Lan at each spoke and the datacenter runs EIGRP (same AS across the board).  This EIGRP process is redistributed into BGP at each location to traverse the MPLS WAN. 

AT&T upgraded our network a year or so back and we were forced to go to BGP over the WAN.  We were using EIGRP with no static and no connected redistribution everywhere before upgrade and had IPSEC backups on our equipment.  With only EIGRP process, all worked great.  Had a couple of static routes for the tunnel and isakmp, and added the tunnel IP to the eigrp process with a delay on tunnel interface. No need for floating static and let EIGRP do all the work. The failover worked fantastically and flipped back once the serial WAN returned to active state.  Now that we have implemented a different WAN protocol (BGP) with EIGRP redistributing into it, i cannot get failover to work properly.  I have to remove the tunnel network from EIGRP now, otherwise a routing loop occurs and the connections fight to establish routes causing loss of functionality.  There has to be something i am missing to make EIGRP use the failover when the MPLS BGP WAN goes down.  Can attach a snippet of config if needed. Thanks for any assistance.

-B

Hi

are you using DMVPN with mGRE protected by ipsec or not ? if not i recommend you to use it as its more scalable and simplify your routing and failover design

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/DMVPN_1.html

and about your failover issue i am not sure how you configured your routers however if you receive same routes over eBGP and EIGRP then it should be simple as eBGP will be preferred !, and do NOT redistribute between EIGRP and BGP, keep them separate in the same router, and if you need to advertise specific routes leaned via eigrp from the lan over bgp you can use the network command under bgp config in this case without redistribution

for the tunnel ipsec/gre connection i would say keep the static route to make sure that the tunnel uses one interface to establish the tunnel and not to go over the ebgp which might cause issues ( in both ends of the tunnel ), in this case you will have the tunnel established and up with eigrp and each router will chose between eBGP or EIGRP routes locally ( no redistribution between EIGRP and BGP required here ) and once the preferred route over eBGP for example disappeared the second protocol (EIGRP) routes will be considered !

see the below document although it is about DMVPN but the concept still applicable for ipsec over gre

https://supportforums.cisco.com/docs/DOC-8356

hope this help

Hi Marwan

Are there any limiation for IPSLA with EEM

Here is the IP SLA example

track 1 ip sla 1 reachability

track 2 ip sla 2 reachability

ip sla 1
icmp-echo 1.1.1.1 source-interface FastEthernet0/0
threshold 500
ip sla schedule 1 life forever start-time now

ip sla 2
icmp-echo 2.2.2.2 source-interface FastEthernet0/1
threshold 500
ip sla schedule 2 life forever start-time now

show ip sla statistics
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
        Latest RTT: 67 milliseconds
Latest operation start time: *12:34:14.449 UTC Thu May 3 2012
Latest operation return code: OK
Number of successes: 37
Number of failures: 0
Operation time to live: Forever

IPSLA operation id: 2
        Latest RTT: 892 milliseconds
Latest operation start time: *12:34:14.649 UTC Thu May 3 2012
Latest operation return code: Over threshold
Number of successes: 37
Number of failures: 0
Operation time to live: Forever

when the IP SLA fails the router should trigger an alert via email, but this seems not to be working. If you had similar case before and working then share your thoughts.

thanks

ST

Hi ST

this is a configurations and EEM issue which is not directly related to the discussed Topic here

i would recommend you to post your question under network management sub-fourm

https://supportforums.cisco.com/community/netpro/network-infrastructure/network-management

however have a look at the below links it might be helpful

http://blog.ioshints.info/2007/11/send-e-mail-when-interface-goes-down.html

http://expertstudynotes.com/index.php?title=Cisco_IOS_Embedded_Event_Manager

Regards,

Marwan,

Thank you for your answer, extremelly helpful. Another question: I was reading a document saying that cisco Nexus 7000 can be configured as access and distribution in the Data center using same physical box with VDC, when this option can be used?

Hi Sarah

The virtual device contexts (VDCs) can be used to virtualize the device itself, presenting the physical switch as multiple logical devices. Within that VDC it can contain its own unique and independent set of VLANs and VRFs. Each VDC can have assigned to it physical ports, thus allowing for the hardware data plane to be virtualized as well.

And based on that Cisco support what is called a Collapsed Architecture with Nexus 7000 using VDCs, where for example small to medium data centers can get the benefit of having a redundant and hierarchal DC design model with less number of N7K physical chassis which make it a cost effective solution.

For example a chassis can be mix of F1/F2/M1 line cards, and the virtualised access layer need layer 2 capabilities only ( cisco N2K FEXs can be used here to increase access ports density), While the virtualized distribution layer requires a line card that support L3 functionality

hope this helps

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: