cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
172686
Views
61
Helpful
68
Comments
Marwan ALshawi
VIP Alumni
VIP Alumni

Introduction

Network Address Translation is a very common feature used to address some issues and also to meet some networks' requirements such as, overlapped networks and Internet links.

In this small document we will discuss a business requirement example, and the main idea behind this example is to demonstrate how to implement and configure NATign with dual homed Internet edge Router  in conjunction with other Cisco IOS advanced features (Policy Based routing PBR and IPSLA ).

Also we will see how all of the above mentioned features work together and how IP SLA will work like a gear to this implementation in term of controlling the exit path of the traffic by controlling the default route in the routing table and PBR decision.

Requirements:

Company XYZ.com has bought a second Internet connection with 1 Mbps in addition to the existing one with 512 Kbps.

the requirement is to load share the traffic over those two links

web traffic and telnet traffic must use the the new ISP link ISP2  and all other traffic must go thorough the old ISP link ISP1

in the case of any of the above links gose down all the traffic should use the remaining link

Note:

this example has been configured in a lab environment and al the private ip addresses used in this document just for the purpose of this example

NAT.jpg

Proposed solution:

According to the above requirements we will use Policy Based routing feature to control LAN traffic going to the Internet and which path to use.

all traffic from the LAN subnet 10.1.1.0/24 destined to tcp 23, 80 and 443 must be routed to ISP 2  link with next hop 172.16.1.2

all other traffic will go though ISP 2 with next hop of 192.168.1.2

as we do not have any subnet or ip ranges to use it over the Internet we have to use NATing with overload option to use the Internet interface IP address

of each ISP link

for example traffic going through ISP 1 will be seen by ISP one and the Internet as it is from 192.168.1.1

if it is through ISP 2 will be seen as it is from 172.16.1.1

In the case of one of the links go down we need all the traffic to use the other remaining link

this will be archived here by using IP SLA with ICMP echo that will be sent to each of the ISP next hop IP addresses in our example 192.168.1.2 and 172.16.1.2

the ICMP echo will be sent every 1 second with time out of 500 msec

if the icmp reply not heard from any of those next hops within 1 second that link will be considered down and the default route in the Internet router pointing to that hop will be withdrawn from the routing table

and the PBR descion will be changed based on that as well

Configurations:

interface FastEthernet1/0

description LAN interface
ip address 10.1.1.1 255.255.255.0
ip nat inside
ip policy route-map PBR    ---- this is for policy based routing

interface FastEthernet1/1

description To ISP 1
ip address 192.168.1.1 255.255.255.0
ip nat outside
!
interface FastEthernet2/0

description To ISP 2
ip address 172.16.1.1 255.255.255.0
ip nat outside

as we can see above the inside interface was configured as inside NAT interface also a policy based routing with a name of PBR applied to that interface, the configurations of this PBR will be described later

both of the Internet ISP links configured as outside NAT interfaces

IP SLA configurations:

ip sla 1
icmp-echo 192.168.1.2
timeout 500
frequency 1
ip sla schedule 1 life forever start-time now


ip sla 2
icmp-echo 172.16.1.2
timeout 500
frequency 1
ip sla schedule 2 life forever start-time now

as we can IP sla 1 will sends icp echo to ISP 1 ip address every 1 second and IP sla 2 will send it to ISP 2

track 10 rtr 1 reachability
delay down 1 up 1
!
track 20 rtr 2 reachability
delay down 1 up 1
!

if ip sla 1 did not get icmp replay within 1 second track 10 will be considered as down ( from ISP 1)

track 20 same for ISP 2

ip route 0.0.0.0 0.0.0.0 192.168.1.2 track 10
ip route 0.0.0.0 0.0.0.0 172.16.1.2 track 20

we have two default routes each one point to one of the ISP's IP address, also each static default route is associated with the corresponding IP SLA track created above

in this case if ISP 1 link is down the first default route will disappear from  the routing table ( we will see this through some verifications command later in his document).

access-list 10 permit 10.1.1.0 0.0.0.255
access-list 100 permit tcp 10.1.1.0 0.0.0.255 any eq telnet
access-list 100 permit tcp 10.1.1.0 0.0.0.255 any eq www
access-list 100 permit tcp 10.1.1.0 0.0.0.255 any eq 443
access-list 101 permit ip any any

these ACLs will be used with PBR and NATing

route-map PBR permit 10
match ip address 100
set ip next-hop verify-availability 172.16.1.2 1 track 20
!
route-map PBR permit 30
match ip address 101
set ip next-hop verify-availability 192.168.1.2 2 track 10
!

we can see from the above route-map called PBR that we have several checks to our traffic coming from the LAN interface towards the Internet

first check is the ACL level

if the traffic soured from our LAN subnet 10.1.1.0/24 and going to any destination using tcp 23, 80 or 443 then this traffic will be match with ACL 100

if any thing else then will be match with ACL 101

In case of telnet traffic tcp 23, this will be match by ACL 100 and route-map sequence 10

but in this sequence we have another check before we send the traffic to the next hope 172.16.1.2, we need to make sure this next hope is up and reachable this is done by the IP SLA /track 20 created above if this track is up then the traffic will be route thorough ISP2 with a next hop 172.16.1.2

if this track 20 is down then the default static route entry points to ISP2 will be withdrawn from the routing table and traffic matched by ACL 100 under the sequence number of 10 of the route-map will be routed according to the normal routing table which is through ISP1 ( because at this stage we have only one default static route left  points to ISP1).  Any other traffic has not matched by ACL 100 will use the route map sequence 30 with the same concept described above

Now we can see how IP SLA controlling the routing table and the  PBR choice !!!

route-map ISP2 permit 10
match ip address 10
match interface FastEthernet2/0
!
route-map ISP1 permit 10
match ip address 10
match interface FastEthernet1/1

those two Route maps will be used by the NAT command

Please note that we have in each of the route-maps match interface this interface representing the exit interface of that nat

this command is important if we do not use it the router always will use the first nating statement and all our traffic will be sourced in our example from 192.168.1.1 !!

we will see that later in this document the effect of removing the match interface from the route-map

ip nat inside source route-map ISP1 interface FastEthernet1/1 overload
ip nat inside source route-map ISP2 interface FastEthernet2/0 overload

this is simply our nating commands each with is corresponding interface and route-map

verifications:

for the verifications purposes we will use a loopback interface created on both ISP routers in our example to represent an destination in the Internet

which is 100100.100.100/32

show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 1, metric 0, candidate default path
  Routing Descriptor Blocks:
    192.168.1.2
      Route metric is 0, traffic share count is 1
  * 172.16.1.2
      Route metric is 0, traffic share count is 1

we have two default route in our routing table which means both ISP routers IP addresses are reachable by SLA icmp echo

show route-map PBR
route-map PBR, permit, sequence 10
  Match clauses:
    ip address (access-lists): 100
  Set clauses:
    ip next-hop verify-availability 172.16.1.2 1 track 20 [up]
  Policy routing matches: 24 packets, 1446 bytes
  route-map PBR, permit, sequence 30
  Match clauses:
    ip address (access-lists): 101
  Set clauses:
    ip next-hop verify-availability 192.168.1.2 2 track 10  [up]
  Policy routing matches: 60 packets, 6840 bytes

both SLA traks 10 and 20 in UP state shown in the route maps show command

now lets ping 100.100.100.100 from the an internal host in subnet 10.1.1.0/24 and we enable debug of NATing on the Internet edge router to see the translated traffic

ping 100.100.100.100

*Dec 19 20:24:44.103: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [80]
*Dec 19 20:24:44.371: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [80]

this is showing us that icmp traffic translated to ->192.168.1.1,

this means that icmp traffic has been match with ACL 101 and because track 10 is up traffic sent to 192.168.1.1 then translated using NAT

this is the PBR debug result for the above ping

*Dec 19 20:25:12.247: IP: s=10.1.1.10 (FastEthernet1/0), d=100.100.100.100, len
100, FIB policy match
*Dec 19 20:25:12.251: IP: s=10.1.1.10 (FastEthernet1/0), d=100.100.100.100, g=19
2.168.1.2, len 100, FIB policy routed
*Dec 19 20:25:12.259: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [81]
*Dec 19 20:25:12.623: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [81]

Now lets see the result when we do a telnet session from the internal network:

telnet 100.100.100.100

*Dec 19 20:26:00.375: IP: s=10.1.1.10 (FastEthernet1/0), d=100.100.100.100, len
44, FIB policy match
*Dec 19 20:26:00.375: IP: s=10.1.1.10 (FastEthernet1/0), d=100.100.100.100, g=17
2.16.1.2, len 44, FIB policy routed
*Dec 19 20:26:00.383: NAT*: s=10.1.1.10->172.16.1.1, d=100.100.100.100 [57504]    --- the traffic used 172.16.1.1 link -----
*Dec 19 20:26:01.159: NAT*: s=100.100.100.100, d=172.16.1.1->10.1.1.10 [25782]

lets shut down ISP1 link to simulated a link down and see how IP SLA will work in this situation:

ping 100.100.100.100

*Dec 19 20:27:54.139: %TRACKING-5-STATE: 10 rtr 1 reachability Up->Down
*Dec 19 20:27:57.895: NAT*: s=10.1.1.10->172.16.1.1, d=100.100.100.100 [82]
*Dec 19 20:27:58.099: NAT*: s=100.100.100.100, d=172.16.1.1->10.1.1.10 [82]

now our ICMP traffic match by ACL 101 is using the link of ISP2 with 172.16.1.1 as the source IP.

we can see bellow that interface connected to ISP 1 is still up, but because the next hop not reachable via ICMP,  IP SLA removed the default route that uses ISP1 next hop from the routing table

interfaces up/up but default route to ISP1 disappeared because of SAL track 10

FastEthernet1/0            10.1.1.1        YES NVRAM  up                    up

FastEthernet1/1            192.168.1.1     YES NVRAM  up                    up

FastEthernet2/0            172.16.1.1      YES manual up                    up

show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 1, metric 0, candidate default path
  Routing Descriptor Blocks:
  * 172.16.1.2
      Route metric is 0, traffic share count is 1

lets bring it back to up now

*Dec 19 20:31:29.143: %TRACKING-5-STATE: 10 rtr 1 reachability Down->Up

Routing entry for 0.0.0.0/0, supernet
  Known via "static", distance 1, metric 0, candidate default path
  Routing Descriptor Blocks:
  * 192.168.1.2
      Route metric is 0, traffic share count is 1
    172.16.1.2
      Route metric is 0, traffic share count is 1

ping 100.100.100.100

*Dec 19 20:32:15.559: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [183]
*Dec 19 20:32:16.071: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [183]

Now lets remove the match interface command from each of the NAT route-maps and see the result

(config)#route-map ISP1
(config-route-map)#no ma
(config-route-map)#no match in
(config-route-map)#no match interface fa1/1
(config-route-map)#route-map ISP2
(config-route-map)#no ma
(config-route-map)#no match int fa2/0
(config-route-map)#

#clear ip nat translation *

then we do ping and telnet we will see al the traffic will be translated to 192.168.1.1 regardless which exit the traffic is using !!!

ping 100.100.100.100

*Dec 19 20:33:47.615: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [184]
*Dec 19 20:33:48.067: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [184]


*Dec 19 20:34:51.675: NAT*: i: tcp (10.1.1.10, 21603) -> (100.100.100.100, 23) [
64704]
*Dec 19 20:34:51.679: NAT*: i: tcp (10.1.1.10, 21603) -> (100.100.100.100, 23) [
64704]
*Dec 19 20:34:51.683: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [64704]
*Dec 19 20:34:51.847: NAT*: o: tcp (100.100.100.100, 23) -> (192.168.1.1, 21603)
[52374]
*Dec 19 20:34:51.847: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [52374]
*Dec 19 20:34:52.123: NAT*: i: tcp (10.1.1.10, 21603) -> (100.100.100.100, 23) [
64705]

lets put match interface back  to the nat route-maps

*Dec 19 20:36:23.379: NAT*: i: icmp (10.1.1.10, 16) -> (100.100.100.100, 16) [18
5]
*Dec 19 20:36:23.383: NAT*: i: icmp (10.1.1.10, 16) -> (100.100.100.100, 16) [18
5]
*Dec 19 20:36:23.387: NAT*: s=10.1.1.10->192.168.1.1, d=100.100.100.100 [185]
*Dec 19 20:36:23.827: NAT*: o: icmp (100.100.100.100, 16) -> (192.168.1.1, 16) [
185]
*Dec 19 20:36:23.827: NAT*: s=100.100.100.100, d=192.168.1.1->10.1.1.10 [185]


telnet 100.100.100.100

*Dec 19 20:36:52.099: NAT*: i: tcp (10.1.1.10, 16305) -> (100.100.100.100, 23) [
46655]
*Dec 19 20:36:52.099: NAT*: i: tcp (10.1.1.10, 16305) -> (100.100.100.100, 23) [
46655]
*Dec 19 20:36:52.103: NAT*: s=10.1.1.10->172.16.1.1, d=100.100.100.100 [46655]
*Dec 19 20:36:52.259: NAT*: o: tcp (100.100.100.100, 23) -> (172.16.1.1, 16305)
[41145]
*Dec 19 20:36:52.259: NAT*: s=100.100.100.100, d=172.16.1.1->10.1.1.10 [41145]
*Dec 19 20:36:52.355: NAT*: i: tcp (10.1.1.10, 16305) -> (100.100.100.100, 23) [
46656]
*Dec 19 20:36:52.359: NAT*: s=10.1.1.10->172.16.1.1, d=100.100.100.100 [46656]
*Dec 19 20:36:52.375: NAT*: i: tcp (10.1.1.10, 16305) -> (100.100.100.100, 23) [
46657]

Conclusion:

to conclude the above configuration example, by using NAT with other Cisco IOS features in particular IP SLA the network will be more automated and reliable, we can track the next hop reachability and we may use other advanced features of IP sla such as link jitter, in the case that we have VOIP traffic. Also by using PBR functionalities we were able to classify our traffic and send it based on the requirements over the two links to avoid congesting one link and leave the other link as passive/back up only.

Thank you

Marwan Alshawi

Comments
Marwan ALshawi
VIP Alumni
VIP Alumni

Hi

well this is not a best practice document or even a recommended way to do load balancing

however it is showing how you can use Cisco's IOS features such as IP SLA and PBR to achieve load balancing over two different Internet links in general

anyway thanks for your comment and you are right each  environment if different and there are multiple ways to achieve Internet load balancing and al depends on the size, load, failover time ..etc

ciscobigcat
Level 1
Level 1

No problem. And I will say it again, your document has to be one of the most straigh forward documents I've seen when it comes to dual ISPs in a single router.

This is a topic in which I have had many endless hours of headaches. And to to be honest, there isnt really a perfect solution. Sometime, what I have ended up is to ask the customer to purchase a second router and then the picture could get a bit better.

Flapping has to be perhaps one of the top obstacles here. When ISPs start to flap, just about any type of IP SLA setup will get affected.

I asked myself one time, ok, I need to setup something which will get triggered soon after a flapping activity is detected and will make the router shutdown the flapping interface (usually ISP1) and re-route all traffic to ISP2. And then the logic should have additional conditions that tells the router, "even if the ISP1 comes back online, do not failback for at least 8 hours".... Obviously the reason for this was to not create more drops on the current TCP established connections that the users already had in ISP2.

But I couldn't found anything solid.

Any insight on this?

alienson13
Level 1
Level 1

Hi ciscobigcat,

Regarding the failback delay, the most near to your requirement is to use the "delay" when tracking an interface so that it won't failover imediately after the interface is up, this will somehow prevent the flapping interface for affecting the network:

delay (tracking)

To specify a period of time to delay communicating state changes of a tracked object, use the delay command in tracking configuration mode. To disable the delay period, use the no form of this command.

delay {up seconds [down seconds] | [up seconds] down seconds}

Usage Guidelines

This command is available to all tracked objects.

If you specify, for example, delay up 10 down 30,  then if the object state changes from down to up, clients tracking that  object are notified after 10 seconds. If the object state changes from  up to down, then clients tracking that object are notified after 30  seconds.

http://www.cisco.com/en/US/docs/ios/12_2sb/feature/guide/sbaiptrk.html

I know this is not a perfect solution since this delay might cause the 2nd link not to be used even if there is no flapping but it is useful, delay up should be used so if the interface came up it won't be reported imdeiately.

Hope this helps

cliendo
Community Member

I tried this but I have to manually clear the NAT translations when a link fails.. Anyway for it to clear the net translations on it's own?

teymur azimov
Level 1
Level 1

Hi Dears.

I configurated dual ISP at router. as you see my configuration i have two subnet: 192.168.20.0 and 192.168.10.0

i do that subnet at dynamic NAT.and they are backup at each other. all of them are perfect working. dynamci nat working perfectly.

i have also one static nat for my mail server(192.168.10.7) i do static nat but the problem is occur.

when i want to access site i can not access and i do ping 4.2.2.2 do not reply at mail server.

but i see this at my nat translation.

ro Inside global      Inside local       Outside local      Outside global

icmp 81.21.95.12:512   192.168.10.7:512   4.2.2.2:512        4.2.2.2:512

tcp 81.21.95.12:4479   192.168.10.7:4479  64.191.223.35:80   64.191.223.35:80

tcp 81.21.95.12:4481   192.168.10.7:4481  64.191.223.35:80   64.191.223.35:80

tcp 81.21.95.12:4482   192.168.10.7:4482  64.191.223.35:80   64.191.223.35:80

tcp 81.21.95.12:4483   192.168.10.7:4483  208.50.223.240:80  208.50.223.240:80

tcp 81.21.95.12:4484   192.168.10.7:4484  208.50.223.240:80  208.50.223.240:80

tcp 81.21.95.12:4485   192.168.10.7:4485  208.50.223.240:80  208.50.223.240:80

udp 81.21.95.10:50462  192.168.10.86:50462 8.8.8.8:53        8.8.8.8:53

this is my pc ip 192.168.10.86 when i ping from my PC as you see the result:

*

*Mar 22 16:25:03.890: NAT*: s=192.168.10.86->81.x.x.10, d=4.2.2.2 [37441]

*Mar 22 16:25:03.974: NAT*: s=4.2.2.2, d=81.x.x.10->192.168.10.86 [10039]

this is my mail server result.

*Mar 22 16:25:07.426: NAT*: s=192.168.10.7->81.x.x.12, d=4.2.2.2 [3696]

no back nat translation.

what is the problem. what i must be change at my configuration.

configuration.

Primary#show run

Building configuration...

Current configuration : 4303 bytes

!

! Last configuration change at 11:48:43 UTC Thu Mar 22 2012

!

version 15.0

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname Primary

!

boot-start-marker

boot-end-marker

!

!

no aaa new-model

!

!

!

!

no ipv6 cef

ip source-route

ip cef

!

!

!

!

!

multilink bundle-name authenticated

!

!

!

!

license udi pid CISCO2901/K9 sn FCZ1516C6A4

!

!

username teymur password 0 cisco

!

redundancy

!

!

track timer interface 5

!

track 1 interface GigabitEthernet0/0 line-protocol

!

track 2 ip sla 1 reachability

delay down 15 up 10

!

track 3 ip sla 2 reachability

delay down 15 up 10

!

!

!

!

crypto dynamic-map dynmap 10

reverse-route

!

!

crypto map clientmap 10 ipsec-isakmp dynamic dynmap

!

!

!

!

!

interface GigabitEthernet0/0

no ip address

duplex auto

speed auto

!

!

interface GigabitEthernet0/0.116

description connected to ISP1

encapsulation dot1Q 116

ip address 81.x.x.10 255.255.255.248

ip nat outside

ip virtual-reassembly

!

interface GigabitEthernet0/0.859

description connected to ISP2

encapsulation dot1Q 859

ip address 85.x.x.114 255.255.255.240

ip nat outside

ip virtual-reassembly

!

interface GigabitEthernet0/1

description INSIDE

ip address 172.25.10.1 255.255.255.0

ip nat inside

ip virtual-reassembly

ip policy route-map Classify

duplex auto

speed auto

standby 1 ip 172.25.10.3

standby 1 priority 110

standby 1 preempt

standby 1 track 1 decrement 20

!

!

ip forward-protocol nd

ip forward-protocol udp isakmp

ip forward-protocol udp non500-isakmp

!

no ip http server

no ip http secure-server

!

ip nat translation timeout 30

ip nat inside source route-map ISP1 interface GigabitEthernet0/0.116 overload

ip nat inside source route-map ISP2 interface GigabitEthernet0/0.859 overload

i

p nat inside source static 192.168.10.7 81.21.95.12 route-map MAIL-Server

ip route 0.0.0.0 0.0.0.0 81.x.x.9

ip route 0.0.0.0 0.0.0.0 85.x.x.113

ip route 192.168.20.0 255.255.255.0 172.25.10.4

ip route 192.168.16.0 255.255.240.0 172.25.10.4

!

ip sla 1

icmp-echo 81.x.x.9 source-interface GigabitEthernet0/0.116

timeout 1000

threshold 1000

frequency 2

ip sla schedule 1 life forever start-time now

ip sla 2

icmp-echo 85.x.x.113 source-interface GigabitEthernet0/0.859

timeout 1000

threshold 1000

frequency 2

ip sla schedule 2 life forever start-time now

access-list 101 deny   ip host 192.168.10.7 any

access-list 101 permit ip 192.168.10.0 0.0.0.255 any

access-list 102 permit ip host 192.168.20.10 any

access-list 103 permit ip 192.168.10.0 0.0.0.255 any

access-list 104 permit ip 192.168.16.0 0.0.7.255 any

access-list 105 permit ip host 192.168.10.7 any

!

!

!

!

route-map MAIL-Server permit 10

match ip address 105

match interface GigabitEthernet0/0.116

!

!

route-map Classify permit 10

match ip address 103

set ip next-hop verify-availability 81.x.x.9 1 track 2

set ip next-hop verify-availability 85.x.x.113 2 track 3

!

route-map Classify permit 20

match ip address 104

set ip next-hop verify-availability 85.x.x.113 1 track 3

set ip next-hop verify-availability 81.x.x.9 2 track 2

!

route-map ISP2 permit 20

match ip address 102 101

match interface GigabitEthernet0/0.859

!

route-map ISP1 permit 10

match ip address 101 102

match interface GigabitEthernet0/0.116

!

!

Hello, I think if you need acces to Mail Server from outside to inside, probably this lines can help you:

ip nat pool Web 192.168.10.7 192.168.10.7 prefix-length 24 (YOUR CUSTOM SUBNET MASK) type rotary

ip nat inside destination list Web_Static_PAT_ACL pool Web

ip access-list extended Web_Static_PAT_ACL

permit tcp any any eq www

permit tcp any any eq 443

permit tcp any any eq 993

permit tcp any any eq 465

permit tcp any any eq 25

Cheers!

parijatkumar
Level 1
Level 1

Hi  marwanshawi,

Could pls reply on following post...I would be very grateful...

https://supportforums.cisco.com/thread/2140989?tstart=0

U have already posted a comment but I am not able to achieve the target...pls help

Thanks...

,

msaa01986
Level 1
Level 1

very nice article but kindly could you confirm using a second set ip next-hop in both route map clauses as the following :

route-map PBR permit 10

match ip address 100

set ip next-hop 172.16.1.2

set ip next-hop 192.168.1.2

!

route-map PBR permit 10

match ip address 101

set ip next-hop 192.168.1.2

set ip next-hop 172.16.1.2

!

so may IPSLA be causes overhead ?????

leon-fans
Community Member

hi marwanshawi  ,

   If the idea can achive load balancing? ,and When I add the Ezvpn server configuration,client can dial-in,also obtain IP addr ,and when client use ping the server(Inside) ,It'll have packet loss;and when disconnect the client and connect again,it'll can be respondly ok and without packet loss .And I want to know what's wrong about this case. everyone can give me an answer ? Thank you very much!

thanks,

Leon

burhanahmed
Level 1
Level 1

what if we have own BGP AS and connected with dual ISP (Multiple AS) than how can we load balance the traffic ?

me.srikanth
Level 1
Level 1

track 10 ip sla 1 reachability
!
track 20 ip sla 2 reachability
!
!
!
!
interface FastEthernet0/0
description WAN-LINK
ip address 119.82.98.50 255.255.255.240 secondary
ip address 202.62.62.122 255.255.255.252
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet0/1
description LOCAL-LAN
ip address 202.62.62.97 255.255.255.248 secondary
ip address 192.168.0.1 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 202.62.62.121 track 10
ip route 0.0.0.0 0.0.0.0 119.82.98.49 track 20
ip route 0.0.0.0 0.0.0.0 202.62.62.121
ip nat inside source list DATA interface FastEthernet0/0 overload
ip nat inside source route-map CITY interface FastEthernet0/0 overload
ip nat inside source route-map SPECTRA interface FastEthernet0/0 overload

ip access-list standard DATA
permit 192.168.0.0 0.0.0.255

ip sla 1
icmp-echo 202.62.77.121
threshold 3
frequency 5
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 119.82.98.49
threshold 3
frequency 5
ip sla schedule 2 life forever start-time now

route-map CITY permit 10
match ip address DATA
match interface FastEthernet0/0
!
route-map SPECTRA permit 10
match ip address DATA
match interface FastEthernet0/0

Hi Guys,
I Have done the configuration like this ,
I was able to use Public ip s of secondary link,but i am unable to ACcess the internet through local ip addresses, when the first is down . i given four 4 dns-server ip addresses also,
ANY ONE can u please give me the solution on this one , It was a great helpful for me
Thanks,

samba.koita
Community Member

Amaizing Post , this really helped me out thank you for sharing !!! 

tejas.dandekar
Level 1
Level 1

Hello Everyone,

do we think the original solution metioned at the top will have some implications if I have IPsec tunnel over the internet link to various destination .

 

 

Regards

Tejas Dandekar

maninthemirrow
Level 1
Level 1

thanks very nice post. but do you think the load on the cpu will be ok. thanks mate

To scale the performance of WAAS / WAE and to provide high reliability, Cisco has a new feature called ITD. Please see ITD (Intelligent Traffic Director) White Paper.

Also, recent blog : Intelligent Traffic Director @ Cisco Live Milan

 

ITD Provides CAPEX and OPEX Savings for Customers

ITD (Intelligent Traffic Director) is a hardware based multi-Tbps Layer 4 load-balancing, traffic steering and clustering solution on Nexus 5K/6K/7K series of switches. It supports IP-stickiness, resiliency, NAT, (EFT), VIP, health monitoring, sophisticated failure handling policies, N+M redundancy, IPv4, IPv6, VRF, weighted load-balancing, bi-directional flow-coherency, and IPSLA probes including DNS.

ITD is much superior than legacy solutions like PBR, WCCP, ECMP, port-channel, layer-4 load-balancer appliances.

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco