Cisco Router + 2ISP + NAT. Service availability through 2 providers

Push. Behind him one more, stronger. That's all. Alpine meadows flashed before my eyes, and the girl in a beige sundress, playfully twirling a lace umbrella in the sharpened handles, rushed past, too. I rushed, not slowing down, despite the fact that I was pulling my less precise but strong little hands towards her, and also with my gestures and mimicry, I depicted, to the best of my strength, what a comprehensive kundyushk could expect her, spread her hands towards me (well, or still that scatter).
But what happened happened, and only a cleverly snatched umbrella from her, by the way, not only exacting and tenacious hands, slightly tinted with pink tones the last seconds of my awakening and warmed a broken heart (without an umbrella covering her hair, the girl turned out to be a little soft speaking, bald). Opening my eyes, I somehow did not see myself, I saw myself not in the midst of the ruins of Niigata, and immediately rejected the seismic nature of the shocks. Slightly relieved. He stopped shouting - “Leave the ship!”. With a reproach, he glanced at the head of the department, shaking me by the shoulder. Which, instead of an apology, brought me the message that the director is waiting for us with him for setting up one small, but very important task. Not taking his words to heart, I tried several times to return to my bald temptress, but the boss continued to show miracles of perseverance. I had to go.

I’ll omit the director’s time in the director’s office and the process of setting us a combat task — you don’t need to know the details of these criminal scenes full of poorly veiled threats and open blackmail, tears and pleadings showing photographs of your parents ’adopted children and raising your arms over your head full of despair. requests not to destroy and throwing the tubes with the already dialed number of the investigator of the security committee (there were ... there were, as you see, I had trumps on my case for such a case - and before that it was necessary to think why I was so zealously throwing a lich but check the Wi-Fi settings on the director's laptops, and now as they say - "Who is your Daddy now, darling? Huh? And BL ### b!?"). But, anyway, the task was set, and she stood in the canvas of the Project server so that the young girls who saw her looked at her cheeks, and the other female team with some, you know, looked at the photographs of their rickety halves at the corners tables of elderly beauties. There was no turning back - the task needed to be solved.

So, the point is that it was necessary to provide remote access to a certain server for a group of people, in order to perform on them a server of a clearly pronounced corruption nature, which do not tolerate delay and unacceptable downtime. The network part of this task put a heavy burden on my fragile shoulders and hugged my neck tightly. It became difficult to breathe and climb stairs to the upper floors.
')
Returning to the office, I sat down to think hard about the task and the ways to get the passport from the pawnshop back without returning money. “Well, something can happen,” I reassured myself, “We have a stable Internet, turn on the cord, and let yourself work, to the delight of people and other criminal elements.” Reporting to the authorities that “The probability of a channel falling is EXTREMELY !!! EXTREMELY LITTLE !!! ”, and taking this thought as an axiom, I, smiling happily, returned to viewing the visions with bald girls in pink sundresses. But, unfortunately, the inquisitive minds of the engineers of our district telecom operator started to approach three (very unpleasant to me from that time) letters - BGP, and actively master all the delights of filtering the path attributes (devised by Shaitan, as we all know). , with which, these engineers, for certain, have direct kinship), and also to test the route selection algorithm for compliance with the declared, not trusting RFC 4274 until the end. Due to the actions of this group of persons by prior agreement (engineers, and further - evil forces), in graciously silence our department more and more frequently heard calls. The verbatim content of the calls is unknown to me, but judging by the appearance of the first gray hair on the head of the head of the department (which is a rather alarming sign at his “zero” hairstyle) and by his rich facial expression, when retelling my impressions of service users about the quality of his (service) provision The situation required surgery.

According to the results of a brief brainstorming by a team of highly professional network engineers (me), it was decided to connect a backup channel. But since the struggle was unfolding not for a certain segment of the route, which could be tracked on sla and in case of which the channel was switched from the main to the reserve, but with the evil forces, who seriously took up the study of BGP, it was necessary to configure the server availability on both channels at the same time (Figure 1). And if the first address from some kind of autonomy was inaccessible (from where the address could be available and from where it was not), the user would connect to the second, but at the same time other users could have access to the server by accessing the first address.

Figure 1.

NOTE: There was of course a little thought to take and use the enemy’s weapon against him, but since at every mention of BGP the whole department jumped up and drew the district with holy signs, it was decided not to write to RIPE with a petition, not to anger God.

So, having on hand the conditions and limitations in solving the problem, a solution was found using the following tools: NAT, static routes, route-maps. Consider this solution on the example shown in Figure 2. The addressing scheme in the example uses only private addresses. The addresses between the office router (R1) and the gate (R2) of the first carrier (ISP1) are changed to 172.16.12.0/29, and between the office router (R1) and the gate (R3) of the second carrier (ISP2) to 172.16.13.0 / 29. The local network, both in life and in the example, uses the private network addresses 192.168.1.0/24, where 192.168.1.1 belong to the router, and 192.168.1.31 to the server.

R1#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 172.16.12.1 YES NVRAM up up
FastEthernet0/1 172.16.13.1 YES manual up up
FastEthernet1/0 192.168.1.1 YES NVRAM up up


For the server NAT, we define the following ip addresses in the pool of each of the providers:
ISP1: 192.168.1.31 -> 172.16.12.4
ISP2: 192.168.1.31 -> 172.16.13.4


Pic2.

We configure server availability on the channel of the first ISP1 provider.
Default route through the first provider:
R1(config)#ip route 0.0.0.0 0.0.0.0 172.16.12.2

Determine the interfaces used in NAT broadcasts:
R1(config)#int fa 0/0
R1(config-if)#ip nat outside
R1(config-if)#int fa 1/0
R1(config-if)#ip nat inside

Natim server
R1(config)#ip nat inside source static 192.168.1.31 172.16.12.4 extendable

That's all - the server is available to users at 172.168.12.4, and this is certainly not worth a close look at the setup site, but is nevertheless necessary for the overall picture.
Now let's move on to setting up server availability on the channel of the second ISP-ISP.
We define the interfaces, use for NAT broadcasts:
R1(config)#int fa 0/1
R1(config-if)#ip nat outside

Natim server
R1(config)#ip nat inside source static 192.168.1.31 172.16.13.4 extendable

And now we come to the most interesting question - how to send answers from the server via the FastEthernet0 / 1 interface, if the client came through ISP 2. The first thing that came to mind, and how it turned out later (the clarification was carried out through several very effective procedures borrowed from the Spanish branch of the tribunal of the sacred office of the Inquisition, and the results are not subject to doubt) is the right decision - this is the use of the route-map. So, on the fa1 / 0 interface, we need to intercept packets returning to clients that came through ISP2. How to fix these packages is not yet completely clear. The source address of the packet is the same - 192.168.1.31, Destination also does not in any way identify the interface from which the packet came to the router. Tension grew, the decision did not come. Prospects for re-encounters with the knee seductress diminished. After abundant googling and reading the treatise “Camouflage and Art: Design for World War 2. Unicorn Press”, the decision came - we put it into the configuration, and we will explain it a little later.
R1(config)#ip nat pool ISP_2nd 192.168.133.0 192.168.133.254 prefix-length 24
R1(config)#access-list 100 permit ip any host 172.16.13.4
R1(config)#ip nat outside source list 100 pool ISP_2nd add-route

For packets arriving at the fa 0/1 interface from the second provider, we broadcast user addresses (source ip address) to the pool 192.168.133.x / 24 and now the return packets to users who access the server through the second operator will be on the fa 1 / interface 0 to have the field dst ip addr = 192.168.133.x that will allow us to rotate the following:

R1(config)#access-list 101 permit ip any 192.168.133.0 0.0.0.255
R1(config)#route-map 2ISP permit 10
R1(config-route-map)#match ip address 101
R1(config-route-map)#set ip next-hop 172.16.13.3
R1(config-route-map)#exit
R1(config)# int fa 1/0
R1(config-if)#ip policy route-map 2ISP

And voila - a workable solution is ready. A brief report to the management, implementation, and ... it would seem - roll that wine pour, burn nearby villages, generally mark as usual the fulfillment of plans for the month and enjoy life, but ... but no. Having collected a lab in GNS3 and, regretting resources for two client hosts, I limited myself to one and noticed the following feature - if the client connects to the server via the second telecom operator to the address 172.16.13.4 in the NAT broadcasts, we get the following lines:
R1#show ip nat translations
Pro Inside global Inside local Outside local Outside global
--- --- --- 192.168.133.1 ZZ.ZZ.ZZ.ZZ
tcp 172.16.13.4:3389 192.168.1.31:3389 192.168.133.1:59324 ZZ.ZZ.ZZ.ZZ:59324

We pay special attention to the first line. Now if for any reason the user is disconnected and reconnected to the address 172.16.12.4 via ISP1, the source address of the packets coming from him will also be translated into pool 192.168.133.x / 24 and the packets from the server going to him will fall under the route map and will be thrown through the fa0 / 1 interface into the ISP2 network. And if the broadcast

t cp 172.16.13.4:3389 192.168.1.31:3389 192.168.133.136:59324 ZZ.ZZ.ZZ.ZZ:59324

over time, zakspayritsya and broadcast to clear up after a timeout, the first one remains hanging, which creates, you see, a serious problem. And, as stated in the advertisement, “What I haven’t tried it with!”, Additional NAT was tried on the first fa 0/0, and attempts to localize the second interface in the VRF, and NVI NAT, and generous bloody retribution of the Ussuri myth tiger “Duse”, and even the right way of building 7 virgin maidens (nude essessno, this is a ritual, not a matinee in elementary school) into the star of David around the router, the eye was delighted, but did not bring the desired result (although judging by the languid faces of some of the colleagues running out of cabinet during the rite - the desired results are different for everyone e). The situation required the prompt collection of the same team of highly professional engineers (not to be confused with the engineers of the evil forces), and she (the situation) received this collection. Well, after that everything is done according to the well-worn scheme - brainstorming, a solution is found, implementation, a report to the authorities, the one with bloody retribution, the scarlet glow over Sosnovka, etc.

Well, let's get down to quicker consideration. The topology does not fix any critical changes, the loopback 0 interface with the IP address 10.0.0.1/32 is uniquely added. As for the used iOS features, this will again be policy based routing.

Figure 3.

We produce the configuration (the configuration is made with 0 - the previous settings are deleted).
Define interfaces for NAT translations:
R1(config)#int fa 0/0
R1(config-if)#ip nat outside
R1(config-if)#int lo0
R1(config-if)#ip nat outside
R1(config-if)#int fa 1/00
R1(config-if)#ip nat inside

It is especially worth noting that now the fa 0/1 interface is not involved in NAT operations.

Add NAT rules:
R1(config)#ip nat inside source static 192.168.1.31 172.16.12.4 extendable
R1(config)#ip nat inside source static 192.168.1.31 172.16.13.4 extendable

Default route through the first provider:
R1(config)#ip route 0.0.0.0 0.0.0.0 172.16.12.2

So, access via fa0 / 0 (via ISP1) is already provided, and as for working through the second operator, if you have not guessed it, the idea is that instead of performing a NAT broadcast on the fa0 / 1 interface, we will redirect incoming packets from this interface to the lo0 interface and natit the server at 172.16.13.4 there. This will give us, in consequence, the possibility of using a route-map on lo0 to trace packets from the server, which must be returned via the second provider and redirect them through fa 0/1, bypassing GRT (general routing table). Total 3 route-maps will be involved in this action:
R1(config)#ip access-list extended from_2ndISP
R1(config-ext-nacl)#permit ip any host 172.16.13.4
R1(config-ext-nacl)#route-map from_2ndISP permit 10
R1(config-route-map)#match ip address from_2ndISP
R1(config-route-map)#set interface Loopback1
R1(config-route-map)#int fa 0/1
R1(config-if)#ip policy route-map from_2ndISP

This routing map (from_2ndISP) will redirect all packets arriving at the fa0 / 1 interface to the lo0 interface where NAT translation and further packet routing to the server will occur via the connected route to the GRT.

Further,
R1(config)#ip access-list extended srv_2_loop
R1(config-ext-nacl)#permit ip host 192.168.1.31 any
R1(config-ext-nacl)# route-map srv_2_loop permit 10
R1(config-route-map)#match ip address srv_2_loop
R1(config-route-map)#set interface Loopback1
R1(config-route-map)#int fa 1/0
R1(config-if)#ip policy route-map srv_2_loop

With the help of this routing map (srv_2_loop) all packets coming from the server will be redirected to the lo0 interface, and the packets in the input queue will get to the interface after passing through the reverse NAT translation (the source field will not be 192.168.1.31 but 172.16.13.4 for sessions initiated through the second telecom operator), which will allow us
R1(config)#ip access-list extended back_2ndISP
R1(config-ext-nacl)#permit ip host 172.16.13.4 any
R1(config-ext-nacl)# route-map back_2ndISP permit 10
R1(config-route-map)#match ip address back_2ndISP
R1(config-route-map)#set ip nex-hop 172.16.13.3
R1(config-route-map)#int fa lo0
R1(config-if)#ip policy route-map back_2ndISP

packets with source 172.16.13.4 will be redirected to the gateway of the second carrier, and everything that did not fall under acl back_2ndISP will be routed using GRT.

That's all. Both options can be considered workers, but the first one in some situations ceases to be such, which makes the second method more reliable, albeit less graceful.

Behind this, I leave you for comprehension (maybe someone had a revelation after reading, so take your time), and I will go for a walk along the picturesque embankments, refreshing the surrounding landscape with my stately figure under a beige lace umbrella.

Used Books:

Jeff Doyle, Jennifer DeHaven Carroll. Routing TCP / IP Volume II (2001 CiscoPress)
I. A. Kryvelev. Bonfire and torture against science and scientists (1933; repr., 1934).
M. M. Scheinman. Fire and blood in the name of God (1924); Papacy (1959); From Pius IX to John XXIII (1966).
AND ABOUT. Susanin. Orienteering and basics of using GLONASS (2010; Polit Publ.)