Simultaneous use of two providers on cisco routers (continued)
Simultaneous use of two providers
If in the first case everything is clear and unambiguous, then in the case of simultaneous use of two providers, problems arise.
To begin with: we need both providers to check for “liveliness” and switch all threads to one in case someone “falls”. This is done completely analogous to the ISP1 check in the chapter on Reservations. With the only difference that both routes by default have the same administrative distance.
NATa rules do not change. The same route-map in dynamic and static broadcasts. But how to determine which package to send through which provider? It is possible to forcibly scatter incoming packets from g0 / 0 with another route-map.
')
The truth is that in this case the packet that got into ACLISP1 will always go to the first provider, regardless of whether the provider is alive or not. To avoid this, it is possible in this route-map to apply a check on the track.
sequence # is a number from 1 to 65535. If there are many such possible next-hop, then they will be ordered by that number.
Let me remind you that if the package does not explicitly fall into the route-map, it will use the usual routing table.
Well, now let's try to deal with two very complex issues: how will the packets go if you do not explicitly use traffic separation using the route-map on the internal interface. And how to make so that the packet that came outside to the address of the Srv server (ISP1) went back through the same interface through which it came. These are really hard questions. And there is no beautiful solution for them, so in my practice I try to avoid such topologies.
However, life can make, so we will understand.
Let the packet come from outside to interface f0 / 0 to the address Srv (ISP1). Thanks to the static broadcast, the destination address will be changed to Srv (LAN) and the packet will go further to the server. A Srv (LAN) and Srv (ISP1) correspondence entry appears on the router in the NAT cache of the broadcasts. The server will answer, the answer will come back to the router and ... a question will arise: what route should the packet be sent to the Internet? In the cache of broadcasts there is an explicit record of what address to put instead of Srv (LAN) - Srv (ISP1). But there is not a hint through which interface to send a packet. To correct this ambiguity, it is necessary, according to some criterion, to separate traffic coming from different interfaces. This can be achieved, but the way, in my opinion, is not very elegant: it is necessary to use the substitution of real addresses of clients for different pools of internal addresses. It is only necessary to choose the size of this pool according to the load on the server - one address for each addressing, since For external NATa (outside NAT) on routers, you cannot make a PAT (Port Address Translation), only the translation of the address to the address. Then it is always known from which interface the request came. As a criterion for server address translation, you can add such access lists to existing route maps.
Thus we get:
This solution, though not beautiful, but still completely solves the problem without affecting the server (it can often not be affected: for example, if it is not an application, but a VPN server). There is only one loss here: the server never knows with whom it actually communicates, which means it is impossible to collect adequate statistics, etc.
If we use the capabilities of servers, then several solutions that do not require external NATa come to mind.
The first is to actually make 2 partner servers, with different addresses and connected to each other for replication with one more link. Each server is broadcast to its address, but in the event of a drop in one of the channels it switches to a partner address.
Not the easiest and cheapest solution.
Second: set 2 addresses on the same server. If they are from the same subnet, then there will be no problems with routing. Each of the local server addresses is strictly broadcast only by one of the providers, since physically, the server is one and we still will not get any benefit from the load. To explicitly specify the output interface, use the route-map STRELKA. There may be a problem with the server itself: it often happens that when the server responds, it uses only the primary address of the interface, regardless of what address the request came to.
A typical example: VPN server. If the cisco router acts as a VPN server, it always responds to the primary interface address.
_________________
I received a letter from a reader from Lithuania, where he referred to an interesting article. Perhaps it will complement the server part of the task:
Here on the site NILA . The author is Ivan Pepelnyak, one of the early CCIEs, a very deep specialist (his blog “iOS hints and tricks”
In short: on the Windows server you can create loopback interfaces (2 pieces) and sorsy the packages from the services from these addresses. And broadcast them to different external. In addition, it is necessary to register return routes on the loopback network on the routers. Then the source address problem will be solved.
__________________
If addresses from different subnets, the default gateway is still the same. So, everything will be routed through only one interface and the task will not be completely solved.
PS Today I finally assembled a stand and checked everything again, thanks to your interest! So use, my dear :)
Sergey Fedorov, CCIE Security # 22974
If in the first case everything is clear and unambiguous, then in the case of simultaneous use of two providers, problems arise.
To begin with: we need both providers to check for “liveliness” and switch all threads to one in case someone “falls”. This is done completely analogous to the ISP1 check in the chapter on Reservations. With the only difference that both routes by default have the same administrative distance.
ip route 0.0.0.0 0.0.0.0 Gate (ISP1) track 11 ip route 0.0.0.0 0.0.0.0 Gate (ISP2) track 22
NATa rules do not change. The same route-map in dynamic and static broadcasts. But how to determine which package to send through which provider? It is possible to forcibly scatter incoming packets from g0 / 0 with another route-map.
')
! We prepare access lists with “interesting” traffic. Everyone knows what is
! "Interesting" traffic? :)
ip access-list extended ACLISP1
permit {traffic to ISP1}
!
ip access-list extended ACLISP2
permit {traffic to ISP2}
!
route-map STRELKA 10
match ip address ACLISP1
set ip next-hop {GateISP1}
route-map STRELKA 20
match ip address ACLISP2
set ip next-hop {GateISP2}
!
int g0 / 0
ip policy route-map STRELKA
The truth is that in this case the packet that got into ACLISP1 will always go to the first provider, regardless of whether the provider is alive or not. To avoid this, it is possible in this route-map to apply a check on the track.
set ip next-hop verify-reachability {GateISPX} {sequence #} track {track #}
sequence # is a number from 1 to 65535. If there are many such possible next-hop, then they will be ordered by that number.
Let me remind you that if the package does not explicitly fall into the route-map, it will use the usual routing table.
Well, now let's try to deal with two very complex issues: how will the packets go if you do not explicitly use traffic separation using the route-map on the internal interface. And how to make so that the packet that came outside to the address of the Srv server (ISP1) went back through the same interface through which it came. These are really hard questions. And there is no beautiful solution for them, so in my practice I try to avoid such topologies.
However, life can make, so we will understand.
Let the packet come from outside to interface f0 / 0 to the address Srv (ISP1). Thanks to the static broadcast, the destination address will be changed to Srv (LAN) and the packet will go further to the server. A Srv (LAN) and Srv (ISP1) correspondence entry appears on the router in the NAT cache of the broadcasts. The server will answer, the answer will come back to the router and ... a question will arise: what route should the packet be sent to the Internet? In the cache of broadcasts there is an explicit record of what address to put instead of Srv (LAN) - Srv (ISP1). But there is not a hint through which interface to send a packet. To correct this ambiguity, it is necessary, according to some criterion, to separate traffic coming from different interfaces. This can be achieved, but the way, in my opinion, is not very elegant: it is necessary to use the substitution of real addresses of clients for different pools of internal addresses. It is only necessary to choose the size of this pool according to the load on the server - one address for each addressing, since For external NATa (outside NAT) on routers, you cannot make a PAT (Port Address Translation), only the translation of the address to the address. Then it is always known from which interface the request came. As a criterion for server address translation, you can add such access lists to existing route maps.
ip access-list extended FORISPX permit ip host Srv (LAN) OUTPOOLX
Thus we get:
! we set pools for each of interfaces
ip nat pool OUTPOOL1 {start-ip-1} {end-ip-1}
ip nat pool OUTPOOL2 {start-ip-2} {end-ip-2}
!
! we set criteria for outside NAT
ip access-list extended OUTNAT1
permit ip any host Srv (ISP1)
ip access-list extended OUTNAT2
permit ip any host Srv (ISP2)
!
! broadcast customer source addresses
ip nat outside source list OUTNAT1 pool OUTPOOL1
ip nat outside source list OUTNAT2 pool OUTPOOL2
!
! add route-map
route-map ISP1 permit 10
match interface f0 / 0
match ip address FORISP1
!
route-map ISP2 permit 10
match interface f0 / 1
match ip address FORISP2
This solution, though not beautiful, but still completely solves the problem without affecting the server (it can often not be affected: for example, if it is not an application, but a VPN server). There is only one loss here: the server never knows with whom it actually communicates, which means it is impossible to collect adequate statistics, etc.
If we use the capabilities of servers, then several solutions that do not require external NATa come to mind.
The first is to actually make 2 partner servers, with different addresses and connected to each other for replication with one more link. Each server is broadcast to its address, but in the event of a drop in one of the channels it switches to a partner address.
Not the easiest and cheapest solution.
Second: set 2 addresses on the same server. If they are from the same subnet, then there will be no problems with routing. Each of the local server addresses is strictly broadcast only by one of the providers, since physically, the server is one and we still will not get any benefit from the load. To explicitly specify the output interface, use the route-map STRELKA. There may be a problem with the server itself: it often happens that when the server responds, it uses only the primary address of the interface, regardless of what address the request came to.
A typical example: VPN server. If the cisco router acts as a VPN server, it always responds to the primary interface address.
_________________
UPD on 23:45 01/14/2010
I received a letter from a reader from Lithuania, where he referred to an interesting article. Perhaps it will complement the server part of the task:
Here on the site NILA . The author is Ivan Pepelnyak, one of the early CCIEs, a very deep specialist (his blog “iOS hints and tricks”
In short: on the Windows server you can create loopback interfaces (2 pieces) and sorsy the packages from the services from these addresses. And broadcast them to different external. In addition, it is necessary to register return routes on the loopback network on the routers. Then the source address problem will be solved.
__________________
If addresses from different subnets, the default gateway is still the same. So, everything will be routed through only one interface and the task will not be completely solved.
PS Today I finally assembled a stand and checked everything again, thanks to your interest! So use, my dear :)
Sergey Fedorov, CCIE Security # 22974
Source: https://habr.com/ru/post/80717/
All Articles