Static and dynamic routing. OSPF Dynamic Routing Protocol

The Lift mi Up network, together with its staff, is growing far and wide. Maintenance of the IT infrastructure was transferred to a separate specially created organization “Link Me Up”.
Just the other day, four more branches were purchased in different cities and investors discovered new dimensions of elevator movement. And the network grew from four routers to ten at once. At the same time, the number of subnets has now increased from 9 to 20, not counting point-to-point links between routers. And here the question of managing this entire economy arises. Agree, manually adding routes to all networks at each node is not much fun.
The situation is complicated by the fact that the network in Kaliningrad already has its own addressing, and the EIGRP dynamic routing protocol is running on it.
So today:

• Let's understand the theory of dynamic routing protocols.
• We introduce the OSPF protocol into the Lift Mi Up network
• Configuring the transfer (redistribution) of routes between OSPF and EIGRP
• In this release we are adding a “Tasks” section. The following icons will help identify them throughout the article:

Dynamic routing protocol theory

For example, if in such a network the link between R2 and R3 is broken, then packets from R1 will continue to go to R2, where they will be destroyed, because there is nowhere to send them.

Dynamic routing protocols within a few seconds (or even milliseconds) learn about problems on the network and rebuild their routing tables, and in the case described above, packets will be sent along the current route

Another important point - traffic balancing. Dynamic routing protocols support this feature almost out of the box and you do not need to add redundant routes manually by calculating them.

Well, the implementation of dynamic routing makes it much easier network scaling. When you add a new element to a network or subnet on an existing router, you only need to perform a few steps to get everything working, with minimal chance of error, and information about the changes is instantly shared across all devices. Exactly the same can be said about global topology changes.

All routing protocols can be divided into two large groups: external ( E.G.P.- Exterior Gateway Protocol) and internal ( IGP- Interior Gateway Protocol). To explain the differences between them, we need the term “autonomous system”. In a general sense, an autonomous system (routing domain) is a group of routers under common management.
In the case of our updated AS network it will be like this:

So, internal routing protocols are used within an autonomous system, and external ones are used to connect autonomous systems with each other. In turn, internal routing protocols are divided into Distance-Vector(RIP, EIGRP) and Link State(OSPF, IS-IS). In this article, we will not kick corpses, touch on the RIP and IGRP protocols due to their venerable age, as well as IS-IS due to its absence in PT.

The fundamental differences between these two types are as follows:
1) the type of information that routers exchange: routing tables for Distance-Vector and topology tables for Link State,
2) the process of choosing the best route,
3) the amount of information about the network that each router “holds in its head”: Distance-Vector knows only its neighbors, Link State has an idea of ​​the entire network.

As we can see, the number of routing protocols is small, but still not one or two. What happens if you run several protocols on the router at the same time? It may be that each protocol will have its own opinion on how best to reach a particular network. What if we also have static routes configured? Who will the router give preference to and whose route will it add to the routing table? The answer to this question is associated with a new term: administrative distance (for our taste, a rather mediocre copy of the English Administrative distance, but they couldn’t come up with a better one). Administrative distance is an integer from 0 to 255, expressing the “measure of confidence” of the router in this route. The smaller the AD, the more trust. Here is a sign of such trust from Cisco’s point of view:

In today's article we will look at OSPF and EIGRP. You will see the first one everywhere and all the time, and the second one is very good in networks where only Cisco equipment is present.
Each of them has its own advantages and disadvantages. We can say that EIGRP is superior to OSPF, but all the advantages are offset by its proprietary nature. EIGRP is a Cisco proprietary protocol and no one else supports it.
In fact, EIGRP has many disadvantages, but this is not particularly discussed in popular articles. Here's just one of the problems: SIA

So let's get started.

OSPF

Let's look at how it works using the example of this simplified network:

To begin with, it must be said that in order for a friendship (adjacency relationship) to develop between routers, the following conditions must be met:

1) the same settings must be configured in OSPF Hello Interval on those routers that are connected to each other. By default it is 10 seconds on Broadcast networks such as Ethernet. This is a kind of KeepAlive message. That is, every 10 seconds, each router sends a Hello packet to its neighbor to say, “Hey, I'm alive,”
2) Must be the same Dead Interval on them. Typically these are 4 Hello intervals - 40 seconds. If no Hello is received from the neighbor during this time, then it is considered unreachable and PANIC begins the process of rebuilding the local database and sending updates to all neighbors.
3) Interfaces connected to each other must be in one subnet,
4) OSPF allows you to reduce the load on the CPU of routers by dividing the Autonomous System into zones. So here it is zone numbers must also match
5) Each router participating in the OSPF process has its own unique identifier - Router ID. If you do not take care of it, the router will select it automatically based on information about the connected interfaces (the highest address is selected from the interfaces active at the time the OSPF process starts). But again, a good engineer has everything under control, so usually a Loopback interface is created, which is assigned an address with a /32 mask and this is what is assigned to the Router ID. This can be convenient for maintenance and troubleshooting.
6) MTU size must match

1) Calm. OSPF Status - DOWN
In this short moment, nothing happens on the network - everyone is silent.

2) The wind is rising: the router sends Hello packets to the multicast address 224.0.0.5 from all interfaces where OSPF is running. The TTL of such messages is one, so only routers located in the same network segment will receive them. R1 goes into state INIT.

The packages contain the following information:

• Router ID
• Hello Interval
• Dead Interval
• Neighbors
• Subnet mask
• Area ID
• Router Priority
• Addresses of DR and BDR routers
• Authentication password

And it sends a new Hello message to R1 using Unicast, which contains the Router ID of this router, and the Neigbors list lists all its neighbors. Among other neighbors in this list there is Router ID R1, that is, R2 already considers it a neighbor.

3) Friendship. When R1 receives this Hello message from R2, it scrolls through the list of neighbors and finds its own Router ID in it, it adds R2 to its list of neighbors.

Now R1 and R2 are mutual neighbors of each other - this means that an adjacency relationship has been established between them and router R1 goes into state TWO WAY.

General advice for all tasks:

Even if you don’t immediately know the answer and solution, try to think about what the condition of the problem refers to:
- What features and protocol settings?
- Are these settings global or tied to a specific interface?
If you don't know or have forgotten a command, such reflections will most likely lead you to the correct context, where you can simply guess or remember how to configure what is required in the task using a hint on the command line.
Try to think in this way before you go to Google or any site looking for commands.

Before we move on to testing backup links and speed, let's do one more useful thing.
If we had the opportunity to catch traffic on the FE0/0.2 msk-arbat-gw1 interface, which faces the servers, then we would see that Hello messages fly off into the unknown every 10 seconds. There is no one to respond to Hello, there is no one to establish adjacency relationships with, so there is no point in trying to send messages from here.
Turning it off is very simple:
msk-arbat-gw1(config)#router OSPF 1
msk-arbat-gw1(config-router)#passive-interface fastEthernet 0/0.2

This command must be given for all interfaces that definitely do not have OSPF neighbors (including those towards the Internet).
As a result, you will have a picture like this:

*I can’t imagine how you haven’t gotten confused yet*

In addition, this command increases security - no one from this network will pretend to be a router and will not try to completely break us.

Now let's move on to the most interesting part - testing.
There is nothing complicated about setting up OSPF on all routers in the Siberian Ring - you can do it yourself.
And after that the picture should be as follows:
msk-arbat-gw1#sh ip OSPF neighbor

172.16.255.32 1 FULL/DR 00:00:31 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:31 172.16.2.18 FastEthernet0/1.5
172.16.255.80 1 FULL/BDR 00:00:36 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/BDR 00:00:37 172.16.2.197 FastEthernet1/0.911

St. Petersburg, Kemerovo, Krasnoyarsk and Vladivostok are directly connected.

msk-arbat-gw1#show ip route

172.16.0.0/16 is variably subnetted, 25 subnets, 6 masks



S 172.16.2.4/30 via 172.16.2.2



O 172.16.2.160/30 via 172.16.2.130, 00:05:53, FastEthernet0/1.8
O 172.16.2.192/30 via 172.16.2.197, 00:04:18, FastEthernet1/0.911





S 172.16.16.0/21 via 172.16.2.2
S 172.16.24.0/22 ​​via 172.16.2.18
O 172.16.24.0/24 via 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.128.0/24 via 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.129.0/26 via 172.16.2.130, 00:07:18, FastEthernet0/1.8

O 172.16.255.32/32 via 172.16.2.2, 00:24:03, FastEthernet0/1.4
O 172.16.255.48/32 via 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.255.80/32 via 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.255.96/32 via 172.16.2.130, 00:04:18, FastEthernet0/1.8
via 172.16.2.197, 00:04:18, FastEthernet1/0.911
O 172.16.255.112/32 via 172.16.2.197, 00:04:28, FastEthernet1/0.911

msk-arbat-gw1#traceroute 172.16.128.1

1 172.16.2.130 35 msec 8 msec 5 msec

Now we tear up the interface between Moscow and Krasnoyarsk and see how long it takes for the link to be restored.
Not even 5 seconds pass before all the routers learned about the incident and recalculated their routing tables:
msk-arbat-gw1(config-subif)#do sh ip ro 172.16.128.0

Known via "OSPF 1", distance 110, metric 4, type intra area
Last update from 172.16.2.197 on FastEthernet1/0.911, 00:00:53 ago
Routing Descriptor Blocks:
* 172.16.2.197, from 172.16.255.80, 00:00:53 ago, via FastEthernet1/0.911
Route metric is 4, traffic share count is 1

Vld-gw1#sh ip route 172.16.128.0
Routing entry for 172.16.128.0/24
Known via "OSPF 1", distance 110, metric 3, type intra area
Last update from 172.16.2.193 on FastEthernet1/0, 00:01:57 ago
Routing Descriptor Blocks:
* 172.16.2.193, from 172.16.255.80, 00:01:57 ago, via FastEthernet1/0
Route metric is 3, traffic share count is 1

Msk-arbat-gw1#traceroute 172.16.128.1
Type escape sequence to abortion.
Tracing the route to 172.16.128.1

1 172.16.2.197 4 msec 10 msec 10 msec
2 172.16.2.193 8 msec 11 msec 15 msec
3 172.16.2.161 15 msec 13 msec 6 msec

That is, now traffic reaches Krasnoyarsk in this way:

As soon as you raise the link, the routers communicate again, exchange their databases, recalculate the shortest paths and enter them into the routing table.
The video makes all this more clear. I recommend get acquainted.

After setting up OSPF on routers in the Siberian ring, all networks that are located behind the router in the central office in Moscow (msk-arbat-gw1) are accessible to Khabarovsk via two routes (via Krasnoyarsk and via Vladivostok). But, since the channel through Krasnoyarsk is better, you need to change the default settings so that Khabarovsk uses the channel through Krasnoyarsk when it is available. And he switched to Vladivostok only if something happened to the channel to Krasnoyarsk.

Like any good protocol, OSPF supports authentication - two neighbors can verify the authenticity of received OSPF messages before establishing adjacency relationships. We leave it to you to study on your own - it’s quite simple.

EIGRP

So, what's good about EIGRP?
- easy to configure
- fast switching on calculated in advance alternate route
- requires less router resources (compared to OSPF)
- summarization of routes on any router (in OSPF only on ABR\ASBR)
- traffic balancing on unequal routes (OSPF only on equal routes)

We decided to translate one of Ivan Pepelnyak’s blog entries, which addresses a number of popular myths about EIGRP:
- “EIGRP is a hybrid routing protocol.” If I remember correctly, this started with the first presentation of EIGRP many years ago and is usually understood as "EIGRP took the best of the link-state and distance-vector protocols." This is absolutely not true. EIGRP does not have any distinctive link-state features. It would be correct to say “EIGRP is an advanced distance-vector routing protocol.”
- “EIGRP is a distance-vector protocol.” Not bad, but not entirely true either. EIGRP differs from other DVs in the way it handles orphaned routes (or routes with increasing metric). All other protocols passively wait for information updates from a neighbor (some, such as RIP, even block the route to prevent routing loops), while EIGRP is more active and requests information itself.
- “EIGRP is difficult to implement and maintain.” Not true. At one time, EIGRP in large networks with low-speed links was difficult to implement correctly, but only until stub routers were introduced. With them (as well as several corrections to the DUAL algorithm), it is almost worse than OSPF.
- “Like LS protocols, EIGRP maintains a table of the topology of the routes that are exchanged.” It's amazing how wrong this is. EIGRP has no idea at all what is beyond its immediate neighbors, while LS protocols know exactly the topology of the entire area to which they are connected.
- “EIGRP is a DV protocol that acts like LS.” Nice try, but still completely wrong. LS protocols build a routing table by going through the following steps:
- each router describes the network based on the information available to it locally (its links, the subnets it is in, the neighbors it sees) through a packet (or several) called an LSA (in OSPF) or LSP (IS-IS)
- LSAs are propagated throughout the network. Each router must receive every LSA created on its network. The information received from the LSA is entered into the topology table.
- Each router independently analyzes its topology table and runs the SPF algorithm to calculate the best routes to each of the other routers
EIGRP's behavior doesn't even come close to these steps, so why on earth it "acts like LS" is unclear.

The only thing EIGRP does is store information received from a neighbor (RIP immediately forgets what cannot be used in at the moment). In this sense, it is similar to BGP, which also stores everything in a BGP table and selects best route from there. The topology table (containing all information received from neighbors) gives EIGRP an advantage over RIP - it can contain information about a backup (not currently used) route.

Each EIGRP process maintains 3 tables:
- A neighbor table, which contains information about “neighbors”, i.e. other routers directly connected to the current one and participating in the exchange of routes. You can view it using the command show ip eigrp neighbors
- Network topology table, which contains routing information received from neighbors. Let's watch as a team show ip eigrp topology
- The routing table, on the basis of which the router makes decisions about redirecting packets. View via show ip route

Metrics.
To assess the quality of a particular route, routing protocols use a certain number that reflects its various characteristics or a set of characteristics - a metric. The characteristics taken into account can be different - from the number of routers on a given route to the arithmetic average of the load on all interfaces along the route. Regarding the EIGRP metric, to quote Jeremy Cioara: “I got the impression that the creators of EIGRP, taking a critical look at their creation, decided that everything was too simple and worked well. And then they came up with a metric formula so that everyone would say “WOW, this is really complicated and looks professional.” See the complete formula for calculating the EIGRP metric: (K1 * bw + (K2 * bw) / (256 - load) + K3 * delay) * (K5 / (reliability + K4)), in which:
- bw is not just bandwidth, but (10000000/smallest bandwidth along the route in kilobits) * 256
- delay is not just a delay, but the sum of all delays on the way to tens of microseconds* 256 (delay in commands show interface, show ip eigrp topology and others is shown in microseconds!)
- K1-K5 are coefficients that serve to ensure that one or another parameter is “included” in the formula.

Scary? it would be if it all worked as written. In fact, of all 4 possible terms of the formula, only two are used by default: bw and delay (coefficients K1 and K3 = 1, the rest are zero), which greatly simplifies it - we simply add these two numbers (while not forgetting that they are still calculated according to their own formulas). It is important to remember the following: the metric is calculated according to the worst throughput indicator along the entire length of the route.
If K5=0, then the following formula is used: Metric = (K1 * bw + (K2 * bw) / (256 - load) + (K3 * delay)

An interesting thing happened with MTU: quite often you can find information that MTU is related to the EIGRP metric. Indeed, MTU values ​​are transmitted when exchanging routes. But, as we can see from the full formula, there is no mention of MTU there. The fact is that this indicator is taken into account in quite specific cases: for example, if a router must discard one of the routes that are equivalent in other characteristics, it will choose the one with a lower MTU. Although, not everything is so simple (see comments).

For each subnet that EIGRP knows about, on each router there is a Successor router from among the neighbors, through which the best (with a lower metric), according to the protocol, route to this subnet goes. In addition, a subnet may also have one or more backup routes (the neighboring router through which such a route goes is called a Feasible Successor). EIGRP is the only routing protocol that remembers backup routes (OSPF has them, but they are contained, so to speak, in “raw form” in the topology table; they still need to be processed by the SPF algorithm), which gives it a performance advantage: as soon as the protocol determines that the main route (via successor) is unavailable, it immediately switches to the backup route. In order for a router to become a feasible successor for a route, its AD must be less than the FD successor of this route (that’s why we need to know AD). This rule is used to avoid routing loops.

Did the previous paragraph blow your mind? The material is difficult, so I’ll use an example again. We have this network:

From R1's point of view, R2 is the Successor for the 192.168.2.0/24 subnet. To become an FS for this subnet, R4 requires that its AD be less than the FD for this route. We have FD ((10000000/1544)*256)+(2100*256) =2195456, R4 has AD (from his point of view this is FD, i.e. how much does it cost him to get to this network) = ((10000000/100000 )*256)+(100*256)=51200. Everything converges, R4’s AD is less than the route’s FD, it becomes FS. *then the brain says: “BDASH”*. Now we look at R3 - he announces his network 192.168.1.0/24 to his neighbor R1, who, in turn, tells his neighbors R2 and R4 about it. R4 is unaware that R2 knows about this subnet and decides to tell him. R2 transmits the information that it has access through R4 to the subnet 192.168.1.0/24 further to R1. R1 strictly looks at the FD of the route and AD, which R2 boasts of (which, as is easy to understand from the diagram, will clearly be larger than the FD, since it includes him too) and shoos him away so as not to interfere with all sorts of nonsense. This situation is quite unlikely, but can occur under certain circumstances, for example, when the split-horizon mechanism is turned off. And now to a more likely situation: imagine that R4 is connected to the 192.168.2.0/24 network not via FastEthernet, but via a 56k modem (the delay for dialup is 20,000 usec), accordingly, it costs him ((10000000/56)*256 )+(2000*256)= 46226176. This is more than the FD for this route, so R4 will not become a Feasible Successor. But this does not mean that EIGRP will not use this route at all. It will just take longer to switch to it (more on that later).

Neighborhood

If the recipient is satisfied with everything, he adds the sender to the list of his neighbors and sends him (already in Unicast) an update packet, which contains a list of all routes known to him (aka full-update). The sender, having received such a packet, in turn, does the same. To exchange routes, EIGRP uses Reliable Transport Protocol (RTP, not to be confused with Real-time Transport Protocol, which is used in IP telephony), which implies delivery confirmation, so each of the routers, having received an update packet, responds with an ack packet (abbreviation from acknowledgement - confirmation). So, the neighborhood relationship has been established, the routers have learned from each other comprehensive information about the routes, what next? Then they will continue to send multicast hello packets to confirm that they are connected, and if the topology changes, update packets containing information only about the changes (partial update).

Now let's return to the previous scheme with the modem.

R2 for some reason lost contact with 192.168.2.0/24. It has no backup routes to this subnet (i.e., no FS). Like any responsible EIGRP router, it wants to reestablish connectivity. To do this, he begins to send special messages (query packets) to all his neighbors, who, in turn, not finding the desired route in themselves, ask all their neighbors, and so on. When the wave of requests reaches R4, he says “wait a minute, I have a route to this subnet! Bad, but at least something. Everyone forgot about him, but I remember.” He packs all this into a reply packet and sends it to the neighbor from whom he received the request (query), and further along the chain. Of course, this all takes more time than just switching to Feasible Successor, but in the end we get communication with the subnet.

And now is a dangerous moment: maybe you have already noticed and become wary after reading about this fan mailing. The failure of one interface causes something similar to a broadcast storm on the network (not on such a scale, of course, but still), and the more routers there are, the more resources will be spent on all these requests and responses. But that's not all that bad. A worse situation is possible: imagine that the routers shown in the picture are only part of a large and distributed network, i.e. some may be located many thousands of kilometers from our R2, on bad channels and so on. So, the trouble is that, having sent a query to a neighbor, the router must wait for a reply from him. It doesn’t matter what the answer is, but it must come. Even if the router already received a positive response, as in our case, he cannot put this route into operation until he waits for a response to all his requests. And maybe there are still requests somewhere in Alaska. This route state is called stuck-in-active. Here we need to get acquainted with the terms that reflect the state of the route in EIGRP: active\passive route. They are usually misleading. Common sense dictates that active means the route is “active”, enabled, running. However, here everything is the other way around: passive means “everything is fine,” and the active state means that this subnet is unavailable, and the router is actively searching for another route, sending out a query and waiting for a reply. So, the stuck-in-active state can last up to 3 minutes! After this period has expired, the router breaks the neighbor relationship with the neighbor from whom it cannot wait for a response, and can use a new route through R4.

A story that chills the blood of a network engineer. 3 minutes of downtime is no joke. How can we avoid the heart attack of this situation? There are two ways out: summing up routes and the so-called stub configuration.

Generally speaking, there is another way out, and it is called route filtering. But this is such a voluminous topic that it would be better to write a separate article on it, but we already have half a book this time. So it's up to you.

The second option is stub configuration. Figuratively speaking, stub means “end of the road”, “dead end” in EIGRP, i.e., to get into some subnet that is not connected directly to such a router, you will have to go back. A router configured as a stub will not forward traffic between subnets that it knows from EIGRP (in other words, which are marked with the letter D in show ip route). In addition, his neighbors will not send him query packets. The most common use case is hub-and-spoke topologies, especially with redundant links. Let’s take this network: on the left are branches, on the right is the main site, main office, etc. For fault tolerance, redundant links. EIGRP is running with default settings.

And now “attention, question”: what will happen if R1 loses connection with R4, and R5 loses LAN? Traffic from the R1 subnet to the main office subnet will follow the route R1->R5->R2 (or R3)->R4. Will it be effective? No. Not only will the subnet behind R1 suffer, but also the subnet behind R2 (or R3), due to the increase in traffic volumes and its consequences. It is for such situations that stub was invented. Behind the routers in the branches there are no other routers that would lead to other subnets, this is the “end of the road”, then only back. Therefore, with a light heart, we can configure them as stubs, which, firstly, will save us from the problem with the “crooked route” outlined just above, and secondly, from the flood of query packets in case of loss of the route.

There are different modes of operation of a stub router; they are set with the eigrp stub command:

R1(config)#router eigrp 1
R1(config-router)#eigrp stub?
connected Do advertise connected routes
leak-map Allow dynamic prefixes based on the leak-map
receive-only Set IP-EIGRP as receive only neighbor
redistributed Do advertise redistributed routes
static Do advertise static routes
summary Do advertise summary routes

Important points in the EIGRP theory that were not included in the article:

• Neighbor authentication can be configured in EIGRP
• Graceful shutdown concept

EIGRP Practice

But bad luck - they already have EIGRP running as a dynamic routing protocol. Moreover, the addressing of end nodes is from a completely different subnet - 10.0.0.0/8. We changed all other parameters (link addresses, loopback interface addresses), but several thousand local network addresses with servers, printers, access points - not a job for a couple of hours - were postponed until later, and in the IP plan we reserved the 172.16 subnet for the future for Kaliningrad .32.0/20.

We currently use the following networks:

How is this miracle configured? Uncomplicated at first glance:
router eigrp 1
network 172.16.0.0 0.0.255.255
network 10.0.0.0

In EIGRP, the reverse mask can be specified, thereby indicating a narrower scope, or not specified, then the standard mask for this class will be selected (16 for class B - 172.16.0.0 and 8 for class A - 10.0.0.0)

Such commands are issued on all Autonomous System routers. The AC is determined by the number in the router eigrp command, that is, in our case we have AC No. 1. This figure should be the same on all routers (unlike OSPF).

But there is a serious catch in EIGRP: by default, automatic summarization of routes in class form is enabled (in IOS versions up to 15).
Let's compare the routing tables on three Kaliningrad routers:

Network 10.0.0.1/24 is connected to klgr-center-gw1 and he knows about it:
klgr-center-gw1:
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.0.0.0/8 is a summary, 00:35:23, Null0
C 10.0.0.0/24 is directly connected, FastEthernet1/0

But doesn't know about 10.0.1.0/24 and 10.0.2.0/24/

Klgr-balt-gw1 knows about his two networks 10.0.1.0/24 and 10.0.2.0/24, but he hid the 10.0.0.0/24 network somewhere.
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D 10.0.0.0/8 is a summary, 00:42:05, Null0
C 10.0.1.0/24 is directly connected, FastEthernet1/1.2
C 10.0.2.0/24 is directly connected, FastEthernet1/1.3

They both created route 10.0.0.0/8 with next hop address Null0.

But klgr-center-gw2 knows that subnets 10.0.0.0/8 are located behind both of its WAN interfaces.
D 10.0.0.0/8 via 172.16.2.41, 00:42:49, FastEthernet0/1
via 172.16.2.45, 00:38:05, FastEthernet0/0

Something very strange is happening.
But, if you check the configuration of this router, you will probably notice:
router eigrp 1
network 172.16.0.0
network 10.0.0.0
auto-summary

Automatic summation is to blame for everything. This is the biggest evil of EIGRP. Let's take a closer look at what's happening. klgr-center-gw1 and klgr-balt-gw1 have subnets from 10.0.0.0/8, they sum them up by default when they pass them on to their neighbors.
That is, for example, klgr-balt-gw1 transmits not two networks 10.0.1.0/24 and 10.0.2.0/24, but one generalized one: 10.0.0.0/8. That is, his neighbor will think that behind klgr-balt-gw1 this entire network is located.
But what happens if suddenly balt-gw1 receives a packet with destination 10.0.50.243, about which it knows nothing? For this case, the so-called Blackhole route is created:
10.0.0.0/8 is a summary, 00:42:05, Null0
The resulting packet will be thrown into this black hole. This is done to avoid routing loops.
So, both of these routers created their own blackhole routes and ignored other people’s announcements. In reality, on such a network, these three devices will not be able to ping each other until... until you disable auto-summary.

The first thing you should do when configuring EIGRP is:
router eigrp 1
no auto-summary

On all devices. And everyone will be fine:

Klgr-center-gw1:
C 10.0.0.0 is directly connected, FastEthernet1/0
D 10.0.1.0 via 172.16.2.37, 00:03:11, FastEthernet0/0
D 10.0.2.0 via 172.16.2.37, 00:03:11, FastEthernet0/0

klgr-balt-gw1
10.0.0.0/24 is subnetted, 3 subnets
D 10.0.0.0 via 172.16.2.38, 00:08:16, FastEthernet0/1
C 10.0.1.0 is directly connected, FastEthernet1/1.2
C 10.0.2.0 is directly connected, FastEthernet1/1.3

klgr-center-gw2:
10.0.0.0/24 is subnetted, 3 subnets
D 10.0.0.0 via 172.16.2.45, 00:11:50, FastEthernet0/0
D 10.0.1.0 via 172.16.2.41, 00:11:48, FastEthernet0/1
D 10.0.2.0 via 172.16.2.41, 00:11:48, FastEthernet0/1

Configuring route transfer between different protocols

To implement it, we need at least one junction point where two protocols will be launched simultaneously. This could be msk-arbat-gw1 or klgr-balt-gw1. Let's choose the second one.

From to EIGRP d OSPF:
klgr-gw1(config)#router ospf 1
klgr-gw1(config-router)#redistribute eigrp 1 subnets

We look at the routes on msk-arbat-gw1:

msk-arbat-gw1#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 198.51.100.1 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O E2 10.0.0.0/8 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.1.0/24 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.2.0/24 via 172.16.2.34, 00:24:50, FastEthernet0/1.7
172.16.0.0/16 is variably subnetted, 30 subnets, 5 masks
O E2 172.16.0.0/16 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
C 172.16.0.0/24 is directly connected, FastEthernet0/0.3
C 172.16.1.0/24 is directly connected, FastEthernet0/0.2
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.2.32/30 is directly connected, FastEthernet0/1.7
O E2 172.16.2.36/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.40/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.44/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
C 172.16.2.128/30 is directly connected, FastEthernet0/1.8
O 172.16.2.160/30 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.2.192/30 via 172.16.2.197, 00:13:21, FastEthernet1/0.911
C 172.16.2.196/30 is directly connected, FastEthernet1/0.911
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.4.0/24 is directly connected, FastEthernet0/0.102
C 172.16.5.0/24 is directly connected, FastEthernet0/0.103
C 172.16.6.0/24 is directly connected, FastEthernet0/0.104
O 172.16.24.0/24 via 172.16.2.18, 01:00:55, FastEthernet0/1.5
O 172.16.128.0/24 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.129.0/26 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.144.0/24 via 172.16.2.130, 00:13:21, FastEthernet0/1.8

O 172.16.160.0/24 via 172.16.2.197, 00:13:31, FastEthernet1/0.911
C 172.16.255.1/32 is directly connected, Loopback0
O 172.16.255.48/32 via 172.16.2.18, 01:00:55, FastEthernet0/1.5
O E2 172.16.255.64/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.65/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.66/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O 172.16.255.80/32 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.255.96/32 via 172.16.2.130, 00:13:21, FastEthernet0/1.8
via 172.16.2.197, 00:13:21, FastEthernet1/0.911
O 172.16.255.112/32 via 172.16.2.197, 00:13:31, FastEthernet1/0.911
198.51.100.0/28 is subnetted, 1 subnets
C 198.51.100.0 is directly connected, FastEthernet0/1.6
S* 0.0.0.0/0 via 198.51.100.1

Now from OSPF to EIGRP. This is a little more complicated:
klgr-gw1(config)#router eigrp 1
klgr-gw1(config-router)#redistribute ospf 1 metric 100000 20 255 1 1500

Without specifying the metric (this long set of numbers), the command will be executed, but redistribution will not occur.

Imported routes receive an EX label in the routing table and an administrative distance of 170, instead of 90 for internal ones:

klgr-gw2#sh ip route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 30 subnets, 4 masks
D EX 172.16.0.0/24 [170 /33280] via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.1.0/24 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.0/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.4/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.16/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D 172.16.2.32/30 [ 90 /30720] via 172.16.2.37, 00:38:59, FastEthernet0/0
C 172.16.2.36/30 is directly connected, FastEthernet0/0
D 172.16.2.40/30 via 172.16.2.37, 00:38:59, FastEthernet0/0
via 172.16.2.46, 00:38:59, FastEthernet0/1
….

Default route

Pinging 192.0.2.2 with 32 bytes of data:

Reply from 172.16.2.5: Destination host unreachable.
Reply from 172.16.2.5: Destination host unreachable.
Reply from 172.16.2.5: Destination host unreachable.

Ping statistics for 192.0.2.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

This is because neither spb-ozerki-gw1, nor spb-vsl-gw1, nor anyone else on our network knows about the default route except msk-arbat-gw1, on which it is statically configured.
To correct this situation, we just need to give one command in Moscow:
msk-arbat-gw1(config)#router ospf 1
msk-arbat-gw1(config-router)#default-information originate

After this, information about where the gateway of last resort is located avalanches across the network.

Internet is now available:
PC>tracert

Tracing route to 192.0.2.2 over a maximum of 30 hops:

1 3 ms 3 ms 3 ms 172.16.17.1
2 4 ms 5 ms 12 ms 172.16.2.5
3 14 ms 20 ms 9 ms 172.16.2.1
4 17 ms 17 ms 19 ms 198.51.100.1
5 22 ms 23 ms 19 ms 192.0.2.2

Useful commands for troubleshooting

Neighbor ID Pri State Dead Time Address Interface
172.16.255.32 1 FULL/DROTHER 00:00:33 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:34 172.16.2.18 FastEthernet0/1.5
172.16.255.64 1 FULL/DR 00:00:33 172.16.2.34 FastEthernet0/1.7
172.16.255.80 1 FULL/DR 00:00:33 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/DR 00:00:33 172.16.2.197 FastEthernet1/0.911

2) Or for EIGRP: show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.2.38 Fa0/1 12 00:04:51 40 1000 0 54
1 172.16.2.42 Fa0/0 13 00:04:51 40 1000 0 58

3) Using the command show ip protocols You can view information about running dynamic routing protocols and their relationships.

Klgr-balt-gw1:
Routing Protocol is "EIGRP 1"

Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: EIGRP 1, OSPF 1
Automatic network summarization is in effect
Automatic address summarization:
Maximum path: 4
Routing for Networks:
172.16.0.0

172.16.2.42 90 4
172.16.2.38 90 4
Distance: internal 90 external 170

Routing Protocol is "OSPF 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 172.16.255.64
It is an autonomous system boundary router
Redistributing External Routes from,
EIGRP 1
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
172.16.2.32 0.0.0.3 area 0
Routing Information Sources:
Gateway Distance Last Update
172.16.255.64 110 00:00:23
Distance: (default is 110)

4) To debug and understand the operation of protocols, it will be useful to use the following commands:
debug ip OSPF events
debug ip OSPF adj
debug EIGRP packets

Try trying different interfaces and see what happens in the debug, what messages are flying.

Authors

I would like to express my gratitude to Dmitry JDima for the edits and invaluable comments, and to the irresistible Natasha Samoilenko for the tasks provided. Anton Avtushko for programming the blog site. And to the girl with the glorious name Nina for the site logo.

P.S.
Our upcoming podcast LinkMiAp needs a jingle and background music. We will be glad to help, and the name of the composer will be glorified for centuries.

P.P.S.
We no longer have enough of Packet Tracer's capabilities. The next step is moving on to something more serious. Any suggestions? I propose to organize a holivar in the comments on the topic IOU vs GNS.

Before delving into the details and features of dynamic routing, let's pay attention to the two-level model, within which the entire set of Internet machines is considered. In this model, the entire Internet is considered as a set of autonomous systems (autonomous system - AS). An autonomous system is a set of computers that form a fairly dense community, where there are many routes between two computers belonging to that community. Within this community, we can talk about optimizing routes in order to achieve maximum information transfer speed. In contrast to this dense conglomerate, autonomous systems are not as tightly coupled as computers within an autonomous system. At the same time, the choice of a route from one autonomous system may be based not on the speed of information exchange, but on reliability, reliability, etc.

Rice. 2.24

The very ideology of autonomous systems arose during the period when ARPANET represented a hierarchical system. At that time there was a system core to which external autonomous systems were connected. Information from one autonomous system to another could only get through kernel routers. This structure is still preserved in MILNET.

In Figure 2.24, the autonomous systems are connected by only one communication line, which is more consistent with how the Russian sector is connected to the Internet. In classic publications on the Internet, the interaction of autonomous parts is often denoted by intersecting circles, emphasizing the fact that there can be several routes from one autonomous system to another.

A discussion of this Internet model is necessary only to explain the two types of dynamic routing protocols: external and internal.

External protocols are used to exchange routing information between autonomous systems.

Internal protocols are used to exchange information about routes within an autonomous system.

In real practice, building local networks, corporate networks and connecting them to providers, you need to know mainly only internal dynamic routing protocols. External dynamic routing protocols are only needed when you want to build a closed, large system that will be connected to the outside world only by a small number of secure data channels.

External protocols include Exterior Gateway Protocol (EGP) and< Protocol Gateway>.

EGP is designed to advertise networks that are accessible to autonomous systems outside of a given autonomous system. According to this protocol, the gateway of one AS transmits to the gateway of another AS information about the networks of which its AS consists. EGP is not used for route optimization. It is believed that internal routing protocols should do this.

BGP is another external routing protocol that came after EGP. In its messages, it already allows you to specify different weights for routes, and thus facilitate the selection of the best route. However, the purpose of these weights is not determined by any independent factors such as access time to a resource or the number of gateways on the path to the resource. Preferences are set by the administrator and therefore sometimes such routing is called political routing, implying that it reflects the technical policy of the administration of a given autonomous system when accessing from other autonomous systems to its information resources. The BGP protocol is used by almost all Russian large IP providers, for example, large nodes of the Relcom network.

Internal protocols include Routing Information Protocol (RIP), HELLO, Intermediate System to Intermediate System (ISIS), Shortest Path First (SPF), and Open Shortest Path First (OSPF).

The RIP (Routing Information Protocol) protocol is designed to automatically update the route table. This uses information about the state of the network, which is sent by routers. According to the RIP protocol, any machine can be a router. At the same time, all routers are divided into active and passive. Active routers report the routes they support on the network. Passive routers read these broadcast messages and correct their routing tables, but do not provide any information to the network themselves. Typically, gateways act as active routers, and ordinary machines (hosts) act as passive routers.

The RIP routing algorithm is based on a simple idea: the more gateways a packet has to go through, the more time it takes to traverse the route. When exchanging messages, routers report to the network the IP number of the network and the number of “hops” that must be made using this route. It should be immediately noted that this algorithm is valid only for networks that have the same transmission speed over any network segment. Often in real life it turns out that it is much more profitable to use fiber optic with 3 gateways than one slow dial-up telephone channel.

Another idea that is designed to solve the problems of RIP is to take into account not the number of hops, but the response time. On this principle, for example, the OSPF protocol is built. In addition, OSPF also implements the idea of ​​flood routing. In RIP, each router exchanges information only with neighbors. As a result, information about the loss of a route in a network several hops away from the local network will be received with a delay. Flood routing solves this problem by notifying all known gateways about changes in the local portion of the network.

Unfortunately, not many systems support multivariate routing. Various Unix and NT clones are mainly oriented towards the RIP protocol. You only need to look at dynamic routing software to see this. The routed program only supports RIP, the gated program supports RIP, HELLO, OSPF, EGP and BGP, and Windows NT only supports RIP.

Therefore, we will consider the possibility of dynamically managing the route table using the RIP protocol only.

Routers operate on packet-switched networks where all possible routes already exist. The process of laying the path is carried out either manually by the administrator (static routing) or automatically by routing protocol (dynamic routing).

Routers, knowing information about the path to some networks, exchange this information with other devices. After such updates all routers will have consistent routing information to available networks. The process of exchanging updates is implemented by routing protocols. Thus, routing protocols share network information between routers.

Changes in the topology take some time ( convergence time) For coordination of information in the routing tables of all routers on the network. Convergence time is an important factor when choosing a routing protocol.

Routing information is collected according to certain rules during the implementation of the dynamic exchange algorithm updates( update , modifications) between routers. Routing protocol must create and maintain routing tables, where paths to all available destination networks are stored, and also notify other routers about all changes in the network topology known to it, i.e. solve a problem network discovery.

The set of networks represented by routers under common administrative control forms autonomous system(Fig. 3.1). Examples of autonomous systems are networks of individual ISPs. Autonomous systems are numbered (AS1, AS2, …AS107, …) and in some protocols (IGRP, EIGRP) these numbers are used during configuration.

Rice. 3.1.

This course covers routing only within an autonomous system, where Interior Gateway Protocols operate. IGP), which include RIP, RIPv2, EIGRP, OSPF, IS-IS. Routing between autonomous systems is carried out by external routing protocols (Exterior Gateway Protocols - E.G.P.). An example of an external routing protocol is BGP, which runs on autonomous system border routers (Figure 3.1).

The set of routing protocols is given in Table. 3.1, from which it follows that dynamic routing protocols operating within autonomous systems, in turn, are divided into distance-vector protocols And link-state protocols.

Protocols distance vector determine the distance and direction, i.e. connection vector in a composite network on the way to the destination. When using the protocol distance vector routers send all or part of the routing table to neighboring (adjacent) routers. In protocols such as R.I.P. And RIP-2 distance is expressed in number of transitions (hop count) in a connection on the path from the source node to the destination. Updates or modifications are exchanged periodically, even if there are no changes in the network, which wastes a significant portion of the bandwidth. Upon receiving an update to the routing information, the router can recalculate all known paths and update the routing table.

Protocols channel status create a complete picture of the network topology and calculate the shortest paths to all destination networks. If there are several paths with the same metric, then the first one calculated is selected. Mailing updates routing information is produced only when network topology changes. Link-state (or link-state) protocols respond more quickly to network changes than distance vector protocols, but are more computationally expensive.

When a frame-encapsulated packet arrives at the ingress interface, the router decapsulates it, then uses the routing table to determine which route to forward the packet to, i.e. to which output interface should the incoming packet be sent?. The output interface is associated with the most efficient route to the destination. This process is called switching or promotion package. At the egress interface, the packet is encapsulated into a new frame, and the router adds information to form the frame (see the materials "Principles and Tools of Internetworking").

Routers are capable of simultaneously supporting several independent protocols with different administrative distances (AD), which show the reliability of the route source. The lower AD, the higher the reliability (see Table 1.1). The routes created by protocols with the shortest administrative distance are installed in the routing table.

The routing protocol determines the most rational (optimal) path based on a certain criterion - metrics. The metric value is used in the evaluation possible ways to the destination. This course covers the following routing protocols:

The listed protocols use different metric parameters.

Different routing protocols use different algorithms when selecting a route, i.e. output interface and/or next-hop address to which the packet should be sent. The algorithm and metric are determined by a number of problems to be solved, such as simplicity, stability, flexibility, fast convergence or convergence. Convergence is the process of agreeing between routers on a network about available routes. When network state changes, it is necessary for the modification exchange to restore consistent network information.

Each algorithm interprets in its own way the choice of the most rational path based on metrics. Usually a lower metric value corresponds to a better route. The metric can be based on one or more path parameters. The most commonly used metrics in routing protocols are:

Best known in Internet networks distance-vector protocol is Routing Information Protocol (RIP), which uses as a metric number of transitions( hop count ) on the way to the destination.

Another simple distance vector protocol is the Interior Gateway Routing Protocol ( IGRP), which was developed by Cisco. To work in large networks, it was replaced by the protocol Enhanced IGRP (EIGRP), which includes many features of both link-state and distance-vector protocols. Therefore, it is essentially a hybrid protocol. However, Cisco developers classify it as a distance-vector protocol.

Distance vector protocols (RIP, IGRP) periodically send updates route information. For the RIP protocol, this period is 30 seconds. This updates the routing tables, which store all information about routes on the network. When a change occurs in the network, a router that detects such a change immediately begins exchanging routing information with neighboring routers. This exchange occurs sequentially from router to router with some delay determined by the time of table modification in each router, as well as a special timer. That's why convergence (convergence) networks, when all routers will have consistent information about network connections, happens slowly, which is a disadvantage of distance vector protocols.

Thus, RIP distance vector protocols are characterized by slow convergence, i.e. long time for reconciling information in routing tables when the network topology changes.

The RIP distance vector protocol uses hop count as a metric to determine the distance to a particular link in a composite network. If multiple paths exist, then RIP will select the path with the fewest number of routers or hops to the destination. However, the chosen route is not always the best way to the destination, since the selected route with the fewest devices may have a lower transmission speed (lower bandwidth, less throughput) compared to alternative routes created by other protocols. In addition, RIP cannot forward packets beyond 15 hops, so it is recommended for small and medium-sized networks. Mailing updates protocol of the first version of RIPv1 is produced in broadcast mode( address 255.255.255.255 ).

The first version of RIPv1 requires that all devices on a subnet use the same subnet mask because RIP does not include subnet mask information in routing updates. This method was called classful routing, which limits the use of the RIPv1 protocol in modern networks.

Distance vector protocol 2nd version RIPVersion 2 ( RIPv2) provides classless CIDR routing(Classless Interdomain Routing) because routing updates include subnet mask information(about the prefix). Moreover, within one network there can be subnets with masks of variable length (Variable-Length Subnet Mask - VLSM). The updates also include address information about default gateways. Distribution of updates using the RIPv2 protocol version is carried out in multicast mode (

Dynamic routing

Static routing is not suitable for large, complex networks because networks typically involve redundant links, multiple protocols, and mixed topologies. Routers in complex networks must quickly adapt to topology changes and select the best route from many candidates.

IP networks have a hierarchical structure. From a routing perspective, a network is viewed as a collection of autonomous systems. In autonomous subsystems of large networks, default routes are widely used for routing to other autonomous systems.

Dynamic routing can be accomplished using one or more protocols. These protocols are often grouped according to where they are used. Protocols for operation within autonomous systems are called interior gateway protocols (IGP), and protocols for operation between autonomous systems are called external gateway protocols (EGP). IGP protocols include RIP, RIP v2, IGRP, EIGRP, OSPF, and IS-IS. The EGP3 and BGP4 protocols are related to EGP. All these protocols can be divided into two classes: distance vector protocols and link state protocols.

Routers use metrics to evaluate or measure routes. When there are many routes from a router to the destination network, and they all use the same routing protocol, then the route with the smallest metric is considered the best. If different routing protocols are used, route selection uses administrative distances that are assigned to routes by the router's operating system.

RIP uses the number of transitions (hops) as a metric. EIGRP uses a complex combination of factors including link bandwidth and link reliability.

The results of the routing protocols are entered into the route table, which constantly changes as the network situation changes. Consider a typical row in a route table related to dynamic routing

R 192.168.14.0/24 via 10.3.0.1 00:00:06 Serial0

Here R defines the routing protocol. So R stands for RIP, and O stands for OSPF, etc. The entry means this route has an administrative distance of 120 and a metric of 3. The router uses these numbers to select a route. The 00:00:06 element specifies the time when this row was updated. Serial0 is the local interface through which the router will forward packets to the 192.168.14.0/24 network through the address 10.3.0.1.

In order for dynamic routing protocols to exchange static route information, additional configuration must be performed.

Distance vector routing

This routing is based on the Belman-Ford algorithm. At certain points in time, the router transmits its entire routing table to neighboring routers. Simple protocols such as RIP and IGRP simply broadcast routing table information across all router interfaces without knowing the exact address of a particular neighboring router.

A neighboring router, when receiving a broadcast, compares the information with its current routing table. Routes to new networks or routes to well-known networks with the best metric. Non-existent routes are deleted. The router adds its own values ​​to the metrics of the received routes. The new routing table is again propagated to neighboring routers (see Figure 1).

font-size:12.0pt;line-height:125%">Fig. 1. Distance vector routing.

Link state protocols

These protocols offer better scalability and convergence compared to distance vector protocols. The protocol is based on Dijkstra's algorithm, often called the shortest path first (SPF) algorithm. The most typical representative is the OSPF (Open Shortest Path First) protocol.

The router takes into account the communication state of the interfaces of other routers on the network. The router builds a complete database of all communication states in its area, that is, it has enough information to create its own map of the network. Each router then independently runs the SPF algorithm on its own network mapping or link-state database to determine the best path, which is entered into the route table. These paths to other networks form a tree with the local router at the top.

Routers advertise their link status to all routers in the area. Such notices are called LSA (link-state advertisements).

Unlike distance vector routers, link-state routers can form ad hoc relationships with their neighbors.

There is an initial influx of LSA packets to build a database of communication states. Further, routes are updated only when communication states change or if the state has not changed within a certain time interval. If the communication state changes, a partial update is sent immediately. It only contains the link states that have changed, not the entire routing table.

The link-conscious administrator finds these partial and infrequent updates an effective alternative to distance vector routing, which transmits the entire routing table at regular intervals.

Link state protocols have faster convergence and best use bandwidth compared to distance vector protocols. They are superior to distance vector protocols for networks of any size, but have two main disadvantages: increased requirements for the processing power of routers and complex administration.

Convergence.

This process is simultaneously and collaborative, and individual. Routers share information among themselves, but independently recalculate their routing tables. For individual routing tables to be accurate, all routers must have the same understanding of the network topology. If the routers agree on the network topology, then they converge. Fast convergence means rapid recovery from broken connections and other changes in the network. Routing protocols and the quality of network design are judged primarily by convergence.

When routers are in the process of convergence, the network is susceptible to routing problems. If some routers determine that a certain link is missing, others mistakenly consider that link to be present. If this happens, the individual route table will be inconsistent, which can lead to packet drops and routing loops.

It is not possible for all routers on a network to detect topology changes at the same time. Depending on the protocol used, it may take a long time until all routing processes in the network converge. The following factors influence this:

Distance in hops to the topology change point.

Number of routers using dynamic protocols.

The effect of some factors can be reduced by careful network design.

Dynamic routing. First acquaintance.

Two routers and five networks

More complex network topology

What if we have a network of several dozen routers, each having a dozen networks? Register a bunch of static routes? Of course not. This is where dynamic routing protocols need to be used.

Dynamic routing protocols periodically distribute information stored in a router's routing table through its interfaces to other routers on the network, and also receive and process similar messages from other routers on the network. Having received such messages, the router extracts unknown routes from them and adds them to its routing table.

In addition to the fact that dynamic routing protocols free network engineers from having to manually plug in hundreds of static routes, dynamic routing protocols also make it possible to increase network fault tolerance by having backup routes. For example, if we have a network like in the picture above. And we were not lazy and added 6 static routes on each device, then everything will work. But before the first accident, if any of the links between the routers disappear, then we will immediately notice a malfunction in the network. If you use dynamic routing, this problem will not arise. In case of an accident, backup routes will be used.

Now a little theory. All dynamic routing protocols can be divided into external routing protocols ( Interior Gateway Protocol, IGP) and internal gateway ( Exterior Gateway Protocol, E.G.P.). Internal gateway protocols are designed for routing within autonomous systems, external gateway protocols are designed for routing between autonomous systems. IN in this case Autonomous system means some large network, under unified control. For example, the network of a large enterprise.

Application of IGP and EGP

When using dynamic routing protocols, all routes placed in the routing table are provided with additional information, called a metric. The metric allows routers to calculate the shortest route to the desired network. In accordance with how the metric is calculated, all dynamic routing protocols can be divided into distance vector ( Distance vector), protocols taking into account the state of channels ( Link-state) and hybrid.

In distance vector routing punctures, the number of intermediate nodes is used as a metric. The fewer intermediate nodes, the more preferable the route will be.

Some network topology

Protocols that take into account the state of channels in their work, oddly enough, take into account the states of channels, and based on these states they calculate metric values.