Dynamic routing. Protocols and work. Internal routing protocols (IGP)

So let's get started.

Articles and videos on how to configure OSPF mountains. There are much fewer descriptions of operating principles. In general, the thing here is that OSPF can be simply configured according to the manuals, without even knowing about SPF algorithms and incomprehensible LSAs. And everything will work and even, most likely, work perfectly - that’s what it’s designed for. That is, it’s not like with vlans, where you had to know the theory down to the header format.
But what distinguishes an engineer from an IT guy is that he understands why his network functions the way it does, and he knows, no worse than OSPF itself, which route will be chosen by the protocol.
Within the framework of the article, which at this moment is already 8,000 characters, we will not be able to dive into the depths of the theory, but we will consider the fundamental points.
It’s very simple and clear, by the way, it’s written about OSPF on xgu.ru or in the English Wikipedia.
So, OSPFv2 works on top of IP, and specifically, it is designed only for IPv4 (OSPFv3 does not depend on layer 3 protocols and therefore can work with IPv6).

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 the PANIC process of rebuilding begins local base data 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) Must match MTU size

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

We are currently interested in the first four, or more precisely, only Router ID and Neighbors.
The Hello message from router R1 carries its Router ID and does not contain Neighbors, because it does not have them yet.
After receiving this multicast message, router R2 adds R1 to its neighbor table (if all the necessary parameters match).

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 the 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 some site looking for commands.

On a real network, when choosing the range of advertised subnets, you need to be guided by regulations and immediate needs.

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#sh 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

Everyone knows everything about everyone.
What route is traffic delivered from Moscow to Krasnoyarsk? The table shows that krs-stolbi-gw1 is connected directly and the same can be seen from the trace:

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 familiarize.

Like anyone good protocol,OSPF supports authentication—two neighbors can verify ,the authenticity of received OSPF messages before establishing ,neighborhood relationships. Leave it on self-study- quite simple.

EIGRP

Now let's move on to another very important protocol.

So, what's good about EIGRP?
- easy to configure
- quick switching to 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 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 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 resembling 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 this 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.

Now a little closer to the theory of work:

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 “include” one or another parameter 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.

An interesting thing happened with MTU: quite often you can find information that MTU is related to the EIGRP metric. And indeed, MTU values transmitted when exchanging routes. But, as we can see from the full formula, there is no mention of MTU. 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).

Let's define the terms used within EIGRP. Each route in EIGRP is characterized by two numbers: Feasible Distance and Advertised Distance (instead of Advertised Distance you can sometimes see Reported Distance, this is the same thing). Each of these numbers represents a metric, or cost (the more, the worse) of a given route from different measurement points: FD is “from me to the destination”, and AD is “from the neighbor who told me about this route to the place appointments." The answer to the logical question “Why do we need to know the cost from a neighbor if it is already included in the FD?” is a little lower (for now you can stop and rack your brains yourself, if you want).

For each subnet that EIGRP knows about, on each router there is a Successor router from among its 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 its AD to 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

Routers don't talk about routes to just anyone - they must establish adjacency relationships before they can start exchanging information. After turning on the process with the router eigrp command, indicating the autonomous system number, we, with the network command, say which interfaces will participate and at the same time, information about which networks we want to distribute. Immediately, hello packets begin to be sent through these interfaces to the multicast address 224.0.0.10 (by default every 5 seconds for ethernet). All routers with EIGRP enabled receive these packets, then each receiving router does the following:
- checks the sender address of the hello packet with the address of the interface from which the packet was received, and makes sure that they are from the same subnet
- compares the values ​​of K-coefficients obtained from the package (in other words, which variables are used in calculating the metric) with its own. It is clear that if they differ, then the metrics for the routes will be calculated according to different rules which is unacceptable
- checks the autonomous system number
- optional: if authentication is configured, checks the consistency of its type and keys.

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, cannot find the desired route at home, 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, etc. 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 in active search 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 expires, 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.

As we already mentioned, in EIGRP route summarization can be carried out on any router. To illustrate, let’s imagine that subnets from 192.168.0.0/24 to 192.168.7.0/24 are connected to our long-suffering R2, which very conveniently sums up to 192.168.0.0/21 (remember binary math). The router advertises this summary route, and everyone else knows: if the destination address begins with 192.168.0-7, then it is to him. What happens if one of the subnets disappears? The router will send query packets with the address of this network (specific, for example, 192.168.5.0/24), but the neighbors, instead of continuing the vicious mailing on their own behalf, will immediately respond with sobering replays, saying that this is your subnet , you figure it out.

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

By default, if you simply issue the eigrp stub command, the connected and summary modes are enabled. Of interest is the receive-only mode, in which the router does not advertise any networks, only listens to what its neighbors tell it (in RIP there is a passive interface command that does the same thing, but in EIGRP it completely disables the protocol on the selected interface, which does not allow establish a neighborhood).

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

Lift mi Up bought a factory in Kaliningrad. The brains of elevators are produced there: microcircuits, software. The factory is very large - three points around the city - three routers connected in a ring.

But bad luck - they already have EIGRP running as a protocol dynamic routing. 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 8 - 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, msk-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 this entire network is located behind msk-balt-gw1.
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

Our task is to organize the transfer of routes between these protocols: from OSPF to EIGRP and vice versa, so that everyone knows the route to any subnet.
This is called route redistribution.

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 EIGRP to 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

Here are the ones with the E2 label - new imported routes. E2 - means that these are external routes of the 2nd type (External), that is, they were introduced into the OSPF process from outside

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
….

This is how it seems to be done in a simple way, but the simplicity is superficial - redistribution is fraught with many subtle and unpleasant moments when at least one redundant link is added between two different domains.
General advice - try to avoid redistribution if possible. The main rule of life works here - the simpler, the better.

Default route

Now is the time to check your Internet access. It works fine from Moscow, but if you check, for example, from St. Petersburg (remember that we deleted all static routes):

PC>ping linkmeup.ru

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 linkmeup.ru

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

1) The list of neighbors and the state of communication with them is called by the command show ip ospf neighbor

msk-arbat-gw1:

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.

Problem No. 7
Finally, a complex problem.
At the last meeting of Lift mi Up, it was decided that the Kaliningrad network should also be transferred to OSPF.
The transition must be completed without interrupting the connection. It was decided that the best option will, in parallel with EIGRP, raise OSPF on three Kaliningrad routers and, after it has been verified that all information about Kaliningrad routes has spread throughout the rest of the network and vice versa, disable EIGRP. for the site logo. Add tags

Dynamic routing. First meeting.

To understand the subject of the conversation, you should first read articles about routers and routing here nearby, otherwise you risk not getting in.
Let's say we have a simple grid like this:

Two routers and five networks

By default, given a given network topology, the “left” router will have entries in its routing table only for three networks directly connected to it: 192.168.1.0/24 , 172.20.0.0/16 And 192.168.100.0/30 . Similarly, the “right” router will only know about networks: 192.168.2.0/24 , 10.0.0.0/8 And 192.168.100.0/30 . And if we try from network 172.20.0.0/16 to access network 192.168.2.0/24, then we won’t get an answer. Of course, we can give routers static routes or standard routes (aka default routes).
Seems like a great solution, right? But what happens if we have this network topology in front of us:

More complex network topology

If in the previous example it was possible to add default routes in one line, or add two static routes with two commands, do this on each device and everything would work, then the situation here is more complicated. Default routes are of little use here, and if you solve the routing problem using static routes, then you will need to register six static routes on each device, which is not so little.

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 disappears, 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 intended for routing between autonomous systems. In this case, an autonomous system means a large network under unified control. For example, a network of a large enterprise.

Application of IGP and EGP

Representatives of the protocol family IGP are the protocols: RIP-1, RIP-2, IGRP, OSPF, EIGRP. TO E.G.P. there is one protocol - BGP.

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. The fewer intermediate nodes, the more preferable the route will be.

Some network topology

Let us have this network topology. From network 1 to network 2 there are two different routes, red and green. In the case of using a distance vector routing protocol, a dedicated route will be more preferable green, since it contains fewer intermediate nodes on the way to the destination network. Classic examples of distance vector routing protocols are the RIP-1 And RIP-2.

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.

Today's article will focus on the main dynamic routing protocol - BGP (Border Gateway Protocol). Why the main one? – Because it is with the help of BGP that the topology of the entire Internet is organized.

So, in this article we will look at the following points:

1. Basic BGP Terms
2. How BGP works
3. BGP Message Types

Terminology

When it comes to BGP, the first thing to consider is the concept of an autonomous system. AS(Autonomus System). An autonomous system is a collection of routing points and connections between them, united by a common communication policy that allows this system to exchange data with nodes located outside its boundaries.

An AS is characterized by a (more recently 32-bit) ASN number (Autonomus System Number) and a pool of IP addresses. The IANA (Internet Assigned Numbers Authority) organization is responsible for issuing both, delegating control over the distribution of ASN and other Internet resources to regional registrars.

The connectivity of autonomous systems is achieved thanks to static or dynamic routing.

With static routing everything is simple. You log into the device and manually specify a route to its nearest neighbor. In practice, connecting even 10 routers with each other seems to be quite a difficult task.

Therefore, for large networks, they came up with dynamic routing, in which devices automatically share information with each other about the routes they have and, moreover, adapt to changes in the topology.

As you know, dynamic routing protocols are classified according to two main characteristics:

1. Type of protocol operation relative to AS

• IGP (Interior Gateway Protocol) – work within an autonomous system. These include: RIP, OSPF, EIGRP, IS-IS
• EGP (Exterior Gateway Protocol) - work outside of autonomous systems and ensure their connectivity. This includes BGP

Protocol operation algorithm

• Distance-Vector - knows routes only to its nearest neighbors and exchanges the routing table with them. (RIP, EIGRP)
• Link State – knows the entire network topology and exchanges the topology table with its neighbors (OSPF, IS-IS)

Obviously BGP cannot be a Link State protocol. Just imagine how many autonomous systems there are on the Internet; any router will simply fail if it receives so much information.

So, BGP is an external routing protocol used to connect two ASes. The diagram looks something like this:

Since BGP has the great task of connecting autonomous systems throughout the Internet, it must be very reliable. For these purposes, at the very beginning of its operation, the BGP router initiates TCP establishment session on port 179 to its neighbor, standard SYN and ACK exchange occurs.

BGP connections must be absolutely negotiated by the autonomous system administrators wishing to establish the connection. If, say, the AS402 administrator launched a BGP process on the BR2 router (Border Router), specifying BR1 and its ASN as a neighbor, and the AS401 administrator did not take any action, then the TCP session will not rise and the systems will remain disconnected. In addition, the following conditions must be met:

1. Port 179 is not blocked by ACL (Access Control List)
2. Routers ping each other
3. When starting a BGP process, the ASN of the remote side was specified correctly
4. RouterIDs do not match

If the TCP session is established successfully, then the BGP routers begin exchanging

OPEN messages, in which they report their ASN, RouterID and Hold timer. Hold timer is the time during which the TCP session will be maintained. If the conditions listed earlier are not met, for example, the information about the AS number does not match, then the message NOTIFICATION a router that receives an incorrect ASN will notify its neighbor and reset the TCP session.

If all conditions are met, then the routers, at a certain interval, begin to send messages to each other KEEPALIVE, meaning confirmation of the parameters adopted in OPEN and the “I’m still alive” notification.

Finally, routers can begin exchanging routing information via message UPDATE. The structure of this message is divided into two parts:

1. Path Attributes. This indicates which AS the route came from, its origin and the Next Hop for this path.
2. NRLI (Network Layer Reachability Information). This indicates information directly about the networks to be added to the routing table, i.e. the IP address of the network and its mask.

The UPDATE message will be sent every time one of the routers receives information about new networks, and the KEEPALIVE message will be sent throughout the entire TCP session.

This is exactly how routing works throughout the Internet. History knows many incidents when the incorrect operation of the BGP protocol led to failures of large parts of the global network, so its importance cannot be underestimated.

Was this article useful to you?

Please tell me why?

We are sorry that the article was not useful for you: (Please, if it is not difficult, indicate why? We will be very grateful for a detailed answer. Thank you for helping us become better!

Figure 3.4 – Autonomous system and routing domain

Autonomous system (AS) is a set of networks that are under a single administrative management and which use a single routing strategy and rules. Autonomous system for external networks appears as a single object.

A routing domain is a collection of networks and routers that use the same routing protocol.

On the Internet, the term autonomous system is used to describe large, logically connected networks, such as Internet service providers. Each such AS has a sixteen-bit number as its identifier. For public networks of Internet providers, the AS number is issued and registered by the American Registry Internet numbers(American Registry of Internet Numbers - ARIN), according to RFC 2270, the range of numbers 64512 - 65534 is allocated for private AS, the autonomous system 65535 is reserved for service tasks.

Routing protocols are divided into two categories: internal (Interior) and external (Exterior).

3.2.2 IGP – internal gateway protocols

Internal protocols are collectively called IGP (Interior Gateway Protocol). This includes any routing protocol used exclusively within an autonomous system, such as RIP, EIGRP, and OSPF. Each IGP protocol represents one routing domain within an AS. There may be multiple IGP domains within an autonomous system (Figure 3.5).

	Border
routing	router

Figure 3.5 – Routing domains within AS

Routers that support the same IGP protocol exchange information with each other within a routing domain. Routers that operate more than one IGP protocol, e.g. RIP protocols and OSPF, are members of two separate domains routing Such routers are called edge routers.

3.2.3 EGP – external gateway protocols

External protocols - EGP (Exterior Gateway Protocol) are routing protocols that provide routing between different autonomous systems. BGP (Border Gateway Protocol) is one of the most

Internal routing protocols (IGP)

Dynamic protocols are divided into two groups:

• 1) EGP (External Gateway Protocol) - external routing protocol for use between autonomous systems (AS).
• 2) IGP (Interior Gateway Protocol) - internal routing protocol for use within an AS.

The internal routing protocols discussed in this subsection ensure synchronization of routers and routes configured between them within the local network. Making a decision on formation best route is formed based on metrics collected by exchanging information with neighboring network gateways. Depending on the metrics and principles of route construction, IGP protocols are in turn divided into distance vector protocols (DVA) and link state protocols (LSP).

Distance vector protocols (DVA)

In distance vector algorithms, each router periodically and broadcasts a vector over the network, the components of which are the distances (measured in one metric or another) from a given router to all networks known to it. Routing protocol packets are commonly called distance advertisements because they are used by a router to advertise to other routers what it knows about the network configuration.

Having received from a certain neighbor a vector of distances to networks known to him, the router increases the components of the vector by the distance from itself to this neighbor. In addition, he supplements the vector with information about other networks known to him, which he learned about directly (if they are connected to his ports) or from similar advertisements of other routers. The router sends the updated vector value to its neighbors. Ultimately, each router learns through neighboring routers information about all the networks present in the composite network and the distances to them.

The disadvantage of distance vector algorithms is that they only work well in relatively small computer networks. Since routers constantly exchange distance vectors, this leads to clogging of communication lines with broadcast traffic in large networks. Another disadvantage of this algorithm is that it does not always respond correctly to changes in the network configuration, since routers transmit only generalized information - a vector of distances, which leads to the fact that routers do not contain a specific idea of ​​​​the topology of connections.

Protocols based on distance vector algorithm:

• 1) RIP is a protocol that operates on transit sections as a routing metric. The maximum number of hops allowed in RIP is 15 (metric 16 means “infinitely large metric”). Each RIP router by default broadcasts its own full table routing once every 30 seconds, quite heavily loading low-speed communication lines;
• 2) EIGRP is a routing protocol developed by Cisco based on the IGRP protocol of the same company. When calculating the metric, the minimum bandwidth (bandwidth) for a given route is used (and not the sum of prices (cost) as in the case of OSPF), which allows you to more accurately determine the more profitable path (route).