cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1142
Views
0
Helpful
22
Replies

ISP load sharing based on subnets

amr2020eg
Level 1
Level 1

i have 2 ISPs connected to my network and VPN connection with HQ 

i have 2 subnets on this branch, i want 172.29.3.0 255.255.255.128 to go through dialer1 and 172.29.3.128 255.255.255.128 to go through FE0/1 which connected to adsl modem

below is configuration but its not working, Please amend if i have any problem with it

ip cef
no ip dhcp use vrf connected
ip dhcp excluded-address 172.29.3.1 172.29.3.10
ip dhcp excluded-address 172.29.3.129 172.29.3.139

!
ip dhcp pool Data
network 172.29.3.0 255.255.255.128
default-router 172.29.3.1
dns-server 192.168.0.29 192.168.0.2 4.2.2.2 4.2.2.3
!
ip dhcp pool Data2
network 172.29.3.128 255.255.255.128
default-router 172.29.3.129
dns-server 192.168.0.29 192.168.0.2 4.2.2.2 4.2.2.3
!
!
no ip domain lookup
no ipv6 cef

interface FastEthernet0/0.2
description <<DATA VLAN INTERFACE>>
encapsulation dot1Q 2
ip address 172.29.3.1 255.255.255.128
ip nat inside
ip virtual-reassembly
\
interface FastEthernet0/0.4
encapsulation dot1Q 4
ip address 172.29.3.129 255.255.255.128

ip nat inside
ip virtual-reassembly

interface Serial0/1/0.16 point-to-point

ip address 172.30.200.2 255.255.255.252
ip nat inside
ip virtual-reassembly
snmp trap link-status
frame-relay interface-dlci 16

interface Dialer1
ip address negotiated
ip mtu 1492
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
ppp authentication pap chap callin

ip policy route-map LO

interface FastEthernet0/1

ip address 192.168.100.2 255.255.255.0
ip nat outside
ip virtual-reassembly in
load-interval 30
duplex auto
speed auto

ip policy route-map CHEM

ip route 0.0.0.0 0.0.0.0 Dialer1

ip route 0.0.0.0 0.0.0.0 192.168.100.1
ip route 10.0.0.0 255.0.0.0 Serial0/1/0.16
ip route 172.16.0.0 255.248.0.0 Serial0/1/0.16

ip nat inside source route-map LO interface dialer1 overload
ip nat inside source route-map CHEM interface Ethernet0/1 overload

!
ip access-list extended ACL-LO
permit ip 172.29.3.0 0.0.0.127 any
ip access-list extended ACL-CHEM
permit ip 172.29.3.128 0.0.0.127 any
!
!
route-map LO permit 10
match ip address ACL-LO
set ip next-hop dialer1
!
route-map CHEM permit 20
match ip address ACL-CHEM
set ip next-hop FastEthernet0/1

Regards,

Amr

1 Accepted Solution

Accepted Solutions

Amr

I think that you do not really understand what I was trying to explain. There are two forms of the set statement in the route map that you need to consider. One form of the set statement is set ip next-hop and the other form of the set statement is set interface. When you use set ip next-hop then you need to use an IP address and when you use set interface then you need to use an interface. It is incorrect and would not work as expected if you configure set ip next-hop dialer1. If you want to specify dialer1 then you need to use the set interface version of the command.

My preference would be to use set ip next-hop in both of the set statements. If you want to use set interface dialer1 that is probably ok. But I suggest that you not use set interface FastEthernet0/1.

Your original post did mention a VPN. But there has not been anything in what you posted that shows any VPN. So it is difficult to determine what is preventing the VPN from working. There is perhaps a clue to the problem when you mention that the VPN is associated with the serial interface. In looking at the partial config that you posted I do see this route which uses the serial interface.

ip route 172.16.0.0 255.248.0.0 Serial0/1/0.16

If you remember that PBR over rides the normal routing table then you can see that with the route maps applied to the LAN subinterfaces that traffic will no longer follow this static route. The way to fix this issue is to change the access list used by PBR. The new access list should deny traffic to the HQ networks and then permit other traffic. It might look something like this

ip access-list extended ACL-LO
 deny ip 172.29.3.0 0.0.0.127 172.16.0.0 0.7.255.255

permit ip 172.29.3.0 0.0.0.127 any

HTH

Rick

HTH

Rick

View solution in original post

22 Replies 22

blau grana
Level 7
Level 7

Hi Amr,

I don't see route-maps applied on LAN interfaces:

interface FastEthernet0/0.2
ip policy route-map LO
interface FastEthernet0/0.4
ip policy route-map CHEM

By the way you can create one route-map and apply it on both LAN interfaces, different ACLs will do the trick.

Also I'm not sure if your NAT config is OK:

ip nat inside source route-map LO interface Ethernet0/1 overload
ip nat inside source route-map CHEM interface Ethernet0/2 overload

Instead of route-maps I would use ACLs which you already created.

More importantly:

  • why are you NATing LO subnet to Eth0/1 and then sent via Dialer interface?
  • why are you NATing CHEM subnet to Eth0/2 and then sent it via Eth0/1?

It seems to me NAT config should look like this:

ip nat inside source list ACL-LO interface Dialer1 overload
ip nat inside source list ACL-CHEM interface Ethernet0/1 overload

Do you have any requirements for failure in case on of the uplinks will go down?

Best Regards Please rate all helpful posts and close solved questions

Hello blau grana,

You right with your NAting statements, and about route-map, please review these changes i created two route-maps for NATing and the other two route-maps are to match LAN sub-interfaces

route-map ISP1 permit 10
match ip address ACL-LO
match interface dialer1
!
route-map ISP2 permit 10
match ip address ACL-CHEM
match interface FastEthernet0/1

interface FastEthernet0/0.2
description <<DATA VLAN INTERFACE>>
encapsulation dot1Q 2
ip address 172.29.3.1 255.255.255.128
ip policy route-map LO
ip nat inside
ip virtual-reassembly

interface FastEthernet0/0.4
encapsulation dot1Q 4
ip address 172.29.3.129 255.255.255.128
ip policy route-map CHEM
ip nat inside
ip virtual-reassembly

ip nat inside source route-map ISP1 interface dialer1 overload
ip nat inside source route-map ISP2 interface FastEthernet0/1 overload

Regards,

Amr

Hello blau grana,

After applying the route-map on LAN sub-interfaces i can't access HQ VPN through Serial0/1/0.16. any help on that

Regards,

Amr

Hello
Your NAT route-maps for dual wan links and PBR config look okay, However the nat interfaces for translation is incorrect:

Try this:

no ip nat inside source route-map LO interface Ethernet0/1 overload
no ip nat inside source route-map CHEM interface Ethernet0/2 overload

ip nat inside source route-map LO interface dialer1 overload
ip nat inside source route-map CHEM interface FastEthernet0/1 overload

int dialer 1
ip tcp adjust-mss 1452

res
Paul


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

It looks to me like the original poster is applying the route map for PBR to the outbound interface (which is a very common mistake). The route map should be applied to the interface which receives the traffic which would be the subinterfaces on FastEth0/0.

When you have two outbound interfaces and you want to do nat differently depending on which interface is being used it is a common solution to use route maps to control the translation. But in the route map there should be two match statements, one match for the access list and the other match for the interface. These route maps are not written this way and so I would not consider them to be correct.

I believe that there are issues when you attempt to use the same route map for two purposes and this config uses LO and CHEM for both PBR and for NAT. I would suggest changing the config so that the existing route maps are used for PBR (and assigned to the appropriate interface) and new route maps are created for nat.

HTH

Rick

HTH

Rick

Hello
LOL - Good spot Richard , Didnt register even though I thought i checked for that.

res
Paul


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Paul

Easy to miss something like this (I know that I have my share of similar misses). One of the very good things about these forums is having multiple people looking at the questions and so multiple opportunities to find the mistakes.

HTH

Rick

HTH

Rick

Hello Richard,

Thanks for your explanation. according to this please review these changes 

route-map ISP1 permit 10
match ip address ACL-LO
match interface dialer1
!
route-map ISP2 permit 10
match ip address ACL-CHEM
match interface FastEthernet0/1

interface FastEthernet0/0.2
description <<DATA VLAN INTERFACE>>
encapsulation dot1Q 2
ip address 172.29.3.1 255.255.255.128
ip policy route-map LO
ip nat inside
ip virtual-reassembly

interface FastEthernet0/0.4
encapsulation dot1Q 4
ip address 172.29.3.129 255.255.255.128
ip policy route-map CHEM
ip nat inside
ip virtual-reassembly

ip nat inside source route-map ISP1 interface dialer1 overload
ip nat inside source route-map ISP2 interface FastEthernet0/1 overload

Regards,

Amr

Amr

I believe that these changes will solve the issue with nat.

In looking further into what was in an earlier post I believe that we still have an issue with the PBR config because it is inconsistent in how it uses the set statements. For reference here is what was in an earlier post

route-map LO permit 10
match ip address ACL-LO
set ip next-hop dialer1
!
route-map CHEM permit 20
match ip address ACL-CHEM
set ip next-hop FastEthernet0/1

The issue is that you are trying to do set ip next-hop but then point to an interface. Either you keep the set ip next-hop and then supply the next hop address or you change the set to use set interface dialer1.

From a syntax perspective either alternative works. From a practical perspective I am concerned about doing set interface when the outbound interface is Ethernet. So I would suggest that you use the set ip next-hop.

HTH

Rick

HTH

Rick

Hello Richard,

Sorry, but to ensure that i understood this, you mean when i point to dailer interface preferred to use  (set ip next-hop dialer1) but when i point to ethernet interface its better to use (set ip next-hop --next hop ip--). is that right?

Thank you very much for your explanations and support

Regards,
Amr

Amr

I think that you do not really understand what I was trying to explain. There are two forms of the set statement in the route map that you need to consider. One form of the set statement is set ip next-hop and the other form of the set statement is set interface. When you use set ip next-hop then you need to use an IP address and when you use set interface then you need to use an interface. It is incorrect and would not work as expected if you configure set ip next-hop dialer1. If you want to specify dialer1 then you need to use the set interface version of the command.

My preference would be to use set ip next-hop in both of the set statements. If you want to use set interface dialer1 that is probably ok. But I suggest that you not use set interface FastEthernet0/1.

Your original post did mention a VPN. But there has not been anything in what you posted that shows any VPN. So it is difficult to determine what is preventing the VPN from working. There is perhaps a clue to the problem when you mention that the VPN is associated with the serial interface. In looking at the partial config that you posted I do see this route which uses the serial interface.

ip route 172.16.0.0 255.248.0.0 Serial0/1/0.16

If you remember that PBR over rides the normal routing table then you can see that with the route maps applied to the LAN subinterfaces that traffic will no longer follow this static route. The way to fix this issue is to change the access list used by PBR. The new access list should deny traffic to the HQ networks and then permit other traffic. It might look something like this

ip access-list extended ACL-LO
 deny ip 172.29.3.0 0.0.0.127 172.16.0.0 0.7.255.255

permit ip 172.29.3.0 0.0.0.127 any

HTH

Rick

HTH

Rick

Dear Richard,

Many thanks for your support and explanations. it sounds working now on my testing environment. I will configure it on branch next available downtime 

Regards,

Amr

Amr

I am glad that you have it working in your test environment and that my suggestions were helpful. I am optimistic that it will work when you configure it on the branch router.

HTH

Rick

HTH

Rick

Dear Richard,

When i configure branch router, the first subnet 172.29.3.0 works fine but the other subnet 172.29.3.128 follows internet route-map correctly but can't reach HQ through VPN. Can you please give me any suggestions on that

Regards,

Amr

Review Cisco Networking products for a $25 gift card