About ospf Virtual links

Something I wrote some time ago, either having too much content at once or having dozens of images in an experiment, is really not suitable for watching after meals. I have to spend some time to drum up, so I decided to do some simple experiments later.

There is actually a lot of research on ospf, such as filtering the FA address and LSA, and even the neighbor creation process can be analyzed from each package, the ospf team, the original SK tribe, has posted many posts. If you want to see them, you can search for them at bbs.sovand.com.

Today we will briefly talk about the establishment of ospf Virtual links. The topology is as follows:

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U31330-0.png "style =" float: none; "title =" 1.png"/>

As we can see, R1 learns the entry in area 2 as), so we need to perform virtual links.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U31204-1.png "style =" float: none; "title =" 2.png"/>

We all know that the virtual link is created using the RID Of the two border routers in the passthrough area. Therefore, first check the RID of R2 and R4. Here, because I set the loopback port before configuring ospf, therefore, 2.2.2.2 and 4.4.4 are used.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U32425-2.png "style =" float: none; "title =" 3.png"/>

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U34040-3.png "style =" float: none; "title =" 4.png"/>

Next, use the target RID to establish a virtual link neighbor. authentication is not used here.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U34338-4.png "style =" float: none; "title =" 5.png"/>

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U31Y4-5.png "style =" float: none; "title =" 6.png"/>

We can see that R2 and R4 start sending hello packets to each other to establish a neighbor relationship through a virtual link, or R2 broadcasts the hello packet to 34.34.34.4, it is a hello packet from Region 0, and R2 can also see that the hello packet sent from R4 is sent from 34.4, after receiving the hello packet sent from R4, immediately replied to a hello packet, this is a direct hello packet, which can be captured when the ospf neighbor relationship is established normally. That is to say, when you receive the hello packet from the neighbor, you will return a hello packet for unicast. If you are interested in multicast or unicast, you can capture the packet.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U32E8-6.png "style =" float: none; "title =" 7.png"/>

The phenomenon seen on R4 is exactly the same as that of R2.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U36263-7.png "style =" float: none; "title =" 8.png"/>

In fact, I want to make it clear that the virtual link is established through the RID connection, but not through the RID address. In general, the RID is an address on a vro ), because the interface of the selected RID, such as the loop interface, may not be advertised to ospf, or to Region 2, it is useless because there is no route, even our RID may be randomly configured, not an interface address.

How can we establish an ospf Virtual link? The two routers that establish the virtual link are in the passthrough area, for example, Region 1 in our environment, we can see a type of LSA in the region's LSDB, so they can also see each other. They can calculate the routing in the zone through Class 1 and Class 2 LSA, and naturally they know that they are arriving at each other, the address that needs to be used.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U35608-8.png "style =" float: none; "title =" 9.png"/>

For example, in the details of a type of LSA, it is easy to find the interface address, and the other 1 and 2 types of LSA in this region can also calculate the route, naturally, they can know which address to send the unicast hello packet and which next hop to send it.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U3Oc-9.png "style =" float: none; "title =" 10.png"/>

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U34053-10.png "style =" float: none; "title =" 11.png"/>

Next, let's take a look at whether I can filter out the route to establish the virtual link's neighbor relationship. Of course, in general, we cannot filter the Class 1 and Class 2 LSA in the same region to see clearly. in general, we can only use the in direction of the distribution list to make the LSDB synchronized, when calculating the route table, some entries are not added to the route table. For example, in the configuration, I filtered out the entries from R4 to the 23.0 CIDR block.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U364b-11.png "style =" float: none; "title =" 12.png"/>

Then we can see that although the virtual link is up, the adjacent State is init, and the prompt is that the hello packet is blocked, because our data packet forwarding will eventually depend on the route table, there is no route in the route table, so the hello packet cannot be sent out.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U33429-12.png "style =" float: none; "title =" 13.png"/>

The first figure below clearly shows that we have also received the hello packet from our neighbors and tried to send the hello packet back directly. The figure below shows that, said our direct hello package restrictions, but also can detect very good fork, this is done in GNS3 phenomenon, on the WEB-IOU, may see the phenomenon content to the extent that: I have sent it two hello, it sent the hello packet neighbor field is still not Lao Tzu, look down on me, then I do not send, that is to say in the WEB-IOU, when R4 sends a few hello packets, it does not, but the phenomenon of GNS3 is that it has been trying to send.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U341M-13.png "style =" float: none; "title =" 14.png"/>

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U32408-14.png "style =" float: none; "title =" 15.png"/>

This experiment is also meaningless, because it was encountered in the troubleshooting of TS, and I think it is a very good phenomenon. It is made for your appreciation.

Next, an interesting command will be provided, that is, a command will be automatically generated when ospf is configured, log-adjacency-changes. This command is used to save the changes in the neighbor relationship as logs, then we will display the log Xixi from the console line by default, so we will see the log when the ospf neighbor is up or down, of course, there will also be an error.

Then we can add a parameter "details" after log-adjacency-changes, that is, the detailed vertex that you display is sprinkled, and the changes in every step of the neighbor relationship are logged, with this parameter, we can easily see the seven state machines of ospf, which are more accurate and simpler than those of the debug ip ospf events.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U3B94-15.png "style =" float: none; "title =" 16.png"/>

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131227/045U31564-16.png "style =" float: none; "title =" 17.png"/>

Well, this is the end. Thank you for watching it. If you have any questions about cy, click the upper right corner to contact Cao Shu via QQ.

This article is from the "Please call me 35004" blog. For more information, contact the author!