Shulou(Shulou.com)06/01 Report--

I haven't come to write an article for some days. on the one hand, I have been studying networking and exams such as ACP, but I have also found that there are no particularly practical technologies to share in blog. Unsurprisingly, I passed the ACP exam last week and found that some networking applications have emerged in cloud computing, although it is difficult to feel the existence of the network when Ali Yun and many companies' cloud platforms are operating. No, no, no. But if the process of using it is so simple, there will be a big problem.

For example, from the concept of network disaster recovery, although you get the maximum simplified experience of network configuration on various cloud platforms, the focus of network engineering will radiate to disaster recovery, security, traffic switching and so on. All these actions should be considered as an operation and maintenance staff, and it will take a lot of energy to do it.

Writing today's article is not about the trend and changes brought about by cloud, and so on. Today is still an introduction to a real case in which we use GRE, IPSEC, BFD to solve the problem of redundant networking and automatic switching. And has a strong "ten thousand essential oil" attribute, in any networking case, there will be such a demand, and the use of standard protocols, so it can be said responsibly, if the enterprise does not have strong capital to support the business expansion of IT when the requirements of high reliability, today's article is worth reading the ideas inside. In a hurry, I simply drew a schematic diagram, as shown below:

The above part is a simplified topology, one is to protect the relevant information of the original case, and the other is to help you to understand.

Project case requirements background:

Disaster recovery data centers need to be deployed, and the private networks of the two data centers are connected through Direct Connect (I use GRE to do the test here, because GRE is equivalent to physical Direct Connect MSTP in terms of functional implementation, so this is done, which is equivalent to talking about the Direct Connect again)

There is no need for dual data centers to work in the same city, just when the connection and exit of the main data center is completely interrupted and the recovery time is out of control, we completely switch our business to the disaster recovery data center.

It is necessary to ensure that there is not only a dedicated line physical line, but also a backup redundant link between the two places, and complete seamless automatic handover can be realized.

PS: I have also omitted the requirements and simplified them. I don't talk too much about DNSPOD, switching on the business side, cluster business, and so on, otherwise I won't finish the article, and I will make it up later.

Project case background:

The export equipment is: Shanshi net T-level product line (very high-end equipment)

Switch Huawei 67 million megabytes

Hundreds of servers

Storage, optical intercourse

Intranet waf, fortress machine, backup all-in-one machine, etc.

PS: here is a detailed description of ignoring all layer 3 devices and implementing this function directly from the mountain and stone network devices, because after the implementation of the mountain and stone, we can split this into layer 3 switches or other router devices. It's just a matter of a few routes. Forgive me for being so arrogant, because routing and switching are really easy to learn. Don't be false, you will learn it one day if you study hard.

Here I will introduce to you with the idea of engineering technology implementation and deployment. Of course, it's the same as before, and the underlying configuration is not detailed.

The first step is to configure GRE. We have configured GRE on FW-An and FW-B. The following is the data configuration method. Please refer to the following. Zone, strategy, routing configuration are not mentioned here. I hope you can learn more comprehensively and not be a hand-out party.

FW-A

Tunnel gre "tofw-b"

Source 210.20.1.1

Destination 200.10.1.1

Key 10

Interface ethernet0/1

Exit

Interface tunnel1

Zone "GRE"

Ip address 1.1.1.1 255.255.255.252

Manage ping

Tunnel gre "tofw-b" gw 1.1.1.2

-

FW-B

Tunnel gre "tofw-a"

Source 200.10.1.1

Destination 210.20.1.1

Key 10

Interface ethernet0/1

Exit

Interface tunnel1

Zone "GRE"

Ip address 1.1.1.2 255.255.255.252

Manage ping

Tunnel gre "tofw-a" gw 1.1.1.1

The second step is to test whether the GRE directly connected address can communicate?

FW-A# ping 1.1.1.2

Sending ICMP packets to 1.1.1.2

Seq ttl time (ms)

1 128 1.09

2 128 0.938

3 128 1.01

4 128 0.962

5 128 0.947

Statistics:

5 packets sent, 5 received, 0 packet loss, time 4005ms

Rtt min/avg/max/mdev = 0.938, 0.989, 1.091, 0.069 ms

Confirming that you can communicate proves that GRE has completed the configuration.

The third step is to test whether the underlying host can communicate on the intranet and test the routing direction.

Host: 10.137.97.1

Ping mapping:

Tracert figure:

Host: 10.137.98.1

Ping mapping:

Tracert figure:

To sum up, the traffic between intranets can be interconnected from GRE at present. The first phase of the requirement is complete, so we now configure the backup line IPSEC, which is still used here for the route pattern IPSEC.

In the second stage, I will not introduce the IPSEC- of Mountain and Stone Network Section, because there is a very detailed introduction in the previous articles. If you are not familiar with it, please refer to the official manual or refer to the previous author's article.

At this time, because the route pattern IPSEC also needs the destination route to communicate, in order to facilitate testing, we temporarily raise the priority of GRE to form a "floating static" with the destination route of IPSEC.

Host: 10.137.97.1

The tracert diagram test is as follows:

Host: 10.137.98.1

The tracert diagram test is as follows:

Well, the configuration of IPSEC is also completed and has passed the business verification. So we need to do a very important step today, that is, how to make its GRE become the main line, IPSEC become the backup line and switch automatically, and when the GRE line is restored, the line will be switched back to the GRE main line again.

In the third stage, BFD is configured to associate BFD in vroute, which is like adding the concept of track and priority to the route, which is not difficult to understand.

FW-A (config) # bfd echo-source-ip 1.1.1.1

FW-A (config-vrouter) # ip route 10.137.98.0 bfd 24 tunnel1 1.1.1.1

FW-B (config) # bfd echo-source-ip 1.1.1.2

FW-B (config-vrouter) # ip route 10.137.97.0 bfd 24 tunnel1 1.1.1.1

PS: here I use the directly connected interface to do the detection. If you have different opinions, of course you can use loopback or other ways to achieve it. There is no fixed configuration mode of thinking.

-

The LOG output is as follows:

FW-A (config-vrouter) # 2017-04-04 01:51:16, Event CRIT@NET: BFD session state changed from Down to Up,local IP:1.1.1.1,neighbor IP:1.1.1.2

FW-B (config-vrouter) # 2017-04-04 01:51:14, Event CRIT@NET: BFD session state changed from Init to Up,local IP:1.1.1.2,neighbor IP:1.1.1.1

Then we adjust the routing of the GRE of the two mountain and stone networks to the default destination route priority of 1magnetic IPsec to 10, as shown below:

FW-A# show ip route

=

S > * 10.137.98.0 via 24 [1max 0max 1max b] 1.1.1.2, tunnel1

S 10.137.98.0/24 [10-0-1] is directly connected, tunnel2

=

FW-B# show ip route

=

S > * 10.137.97.0 via 24 [1max 0max 1max b] 1.1.1.1, tunnel1

S 10.137.97.0/24 [10-0-1] is directly connected, tunnel2

=

PS: simplified above

Conclusion: it can be found that the floating static state has been formed in the routing table, and the BFD function has been successfully hung in the routing of tunnel. So now we can do a perfect failover.

During the switching process, it belongs to dynamic observation, while blog can only upload static images, so I will briefly describe it here. Because indeed in the course of my testing, I was surprised by the complete seamless handover, without any increase in packet loss and latency. In short, if you listen to me, you might as well test the real experience, which will be a little more profound.

Fault simulation:

The tunnel interface of shutdown GRE is like a physical dedicated line failure.

The following is a screenshot of the process of testing the failure, [no]

Host: 10.137.97.1

The situation of ping packets before and after switching, the moment after the interruption, and the tracert chart before and after the interruption:

Host: 10.137.98.1

The situation of ping packets before and after switching, the moment after the interruption, and the tracert chart before and after the interruption:

Then when I execute the tunnel interface no shut again, the situation is exactly the same. So the screenshot here is omitted.

When simulating a failure, the underlying log of BFD prompts:

FW-A# 2017-04-04 03:16:38, Event CRIT@NET: BFD session state changed from Up to Down,local IP:1.1.1.1,neighbor IP:1.1.1.2

When simulating fault recovery, the underlying log of BFD prompts:

FW-A# 2017-04-04 03:21:50, Event CRIT@NET: BFD session state changed from Down to Up,local IP:1.1.1.1,neighbor IP:1.1.1.2

Conclusion:

Shanshi Netcom has passed the verification of the hot redundancy scheme of the two-point direct connect through GRE+IPSEC+BFD, and can go to PPT to write the scheme.

In the end, of course, I need to remind you again that this is an experimental environment, and the network situation is relatively closed and stable, and it is impossible to objectively show the failure scenario of the wide area network. at least it will not be broken by the "excavator" optical cable, the light attenuation is too weak, the equipment failure, and so on, so the network has a long and long way to go, even unfathomable. However, the network is still the biggest contributor to changing the way all services are supported, so I hope everyone will not ignore the importance of the network. Don't be arrogant and think that you will configure several static routes and configure a few xxx that you have nothing to learn from the network.

-shared by network workers from a second-tier operator

Regard learning as a habit, hard work as a life motto, and sharing into everyone's strength.

QQ:549675970

[welcome to join me to exchange technical experience and learn from each other]

QZONE: http://user.qzone.qq.com/549675970

E-mail:

549675970@qq.com

Allen_junjun@hotmail.com

Life motto: the harder you work, the luckier you are.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.