ODR - On-Demand Routing

1. Introduction to ODR - On-Demand Routing

Before learning the ODR technology, let's recall two main methods of filling routing tables with information:

• Static routing - routes are added manually by the administrator.
• Dynamic routing - the administrator configures dynamic routing protocols.

But in each of these cases there are drawbacks:

• The main disadvantage of static routing is the need to reconfigure devices when changing the network structure or addresses.
• The main disadvantages of dynamic routing drawbacks are: additional load on the channels and a decrease in security.

In principle, it cannot be said that these shortcomings are significant in modern conditions. It is unlikely that networks will often be reconfigured, modern communication channels are wide enough to transfer relatively small traffic generated by routing protocols without problems. And even the problem of external dynamic IP addresses received from the provider can be solved by using dynamic DNS technology.

But in fact there is another drawback common to both options - you need support staff at every point where the router is located. The one who will prescribe static routes or configure a dynamic routing protocol.

For such cases, Cisco has developed a proprietary protocol ODR, which in fact is not even a dynamic configuration protocol, it is an extension of another proprietary protocol - CDP. Using the ODR protocol, routers can exchange routing information in a specific way (as a result, the amount of information transmitted is substantially less than that of other dynamic routing protocols), and the configuration of all routers on the network is not required. Only one router is configured - the main router of the company; all other routers do not require any routing configuration at all , neither static nor dynamic.

Thus, it turns out that ODR does not have the above disadvantages:

• The amount of data transferred is minimal compared to the protocols of dynamic routing protocols.
• Requires minimal configuration on a single router.

However, ODR has a disadvantage, or rather a limitation - it can only be applied in the star topology (the term “hub-and-spoke” is often used in English literature). That is, if no more than one hop (jump) is removed from the central router of the branch network. In more complex topologies, this protocol does not work. An example of such a topology is shown in Figure 1-1. R1 is the central router ("hub"), R2 and R3 routers are the remote branch routers ("spoke").

Figure 1-1. Network with a star topology (“hub-and-spoke”).

2. The principle of ODR

As mentioned above, ODR is not a full-featured dynamic routing protocol. ODR is an extension of the CDP protocol, and in order to understand how ODR transmits information using CDP, you need to parse the basic principles of this protocol, so a slight digression.

The device (router or switch) regularly sends special CDP (Cisco Discovery Protocol) messages to the group MAC address 01-00-0c-cc-cc-cc. By default, this happens every 60 seconds. If a device that understands this protocol receives a similar message, it enters the information contained in it in a special table and considers the sender of this message as its “CDP neighbor.” If no messages are received from the neighbor during the three mailing interval, then information about it is deleted from this table. Mailing and deletion timers are configurable; you can read about them in the CDP protocol course.

The main purpose of the CDP protocol is to enable devices located on the same channel network to receive information about each other, even if different protocols are used at the network layer.

The CDP protocol provides information transfer in the form of TLV (Type / Length / Value - type / length / value) blocks. That is, the data field has a variable length and depends on the type and number of TLV blocks included in the message. At the same time, situations are possible when the devices, for example, due to different production dates, “know” a different set of TVL blocks. But this does not interfere with the devices to interact normally, since the format of these blocks is standard, and if a block comes with an unknown “Type” field, then based on the “Length” field, you can simply skip the “Value” field and move on to the next block.

An example of a CDP frame is shown in Figure 2-1.

Figure 2-1. An example of a CDP frame captured by a traffic analyzer.

So, to implement the protocol ODR, Cisco has used the ability to extend the protocol CDP. A new type, 0x0007 , was added to it , and with it, routers can exchange routing information in a very limited way.

The structure of this option is the same:

• Type - 0x0007
• Length - the length of the entire option, depending on the amount of data transferred.

When transferring data from the central router, the data length is always 4 bytes - the IP address that the remote router should use as the default gateway, as a result, the whole option will be 8 bytes long. An example of such an option is shown in Figure 2-2.

When transferring data from a remote router, the data length is variable, the message shows the numbers of one or several networks connected to this router in the format “4 bytes IP address, and 1 byte mask”. These networks will be added by the central router to the routing table. As a result, the length of the entire option will be - 4 + N * 5 (where N is the number of networks connected to the remote router, except for the network through which it communicates with the central one). An example of such an option is shown in Figure 2-3.

• Value - IP address of the gateway, or a set of networks, depending on the direction in which the packet is sent.

Figure 2-2. An example of a CDP frame captured by the traffic analyzer with the ODR option transmitted from the central router is the address that should be used by the remote router as the default gateway.



Figure 2-3. An example of a CDP frame captured by the traffic analyzer with the ODR option transmitted to the central router is transmitted to the network addresses that the central router must add to the routing table.

3. Configure ODR

First of all, we should not forget that ODR runs on top of CDP, and it must be enabled on all routers ( cdp run command in global configuration mode).

Enabling On-Demand Routing is performed only on the central router by entering the router odr command in global configuration mode. However, unlike other dynamic routing protocols, no commands are required any more (for example, network ). An example of setting up the ODR protocol is shown in Figure 3-1; as you can see, only one router odr command has been entered .

Figure 3-1. An example of setting the protocol ODR.



At the same time, the central router on all its interfaces includes in the CDP ODR distribution an option that will indicate the IP address that the remote routers should use as a gateway. All remote routers that see this option in CDP packets, and no dynamic routing protocol is configured on them ( this is a prerequisite ), include in their CDP the same option with information about the connected networks (except the one that belongs to the interface) which these ads are sent).

Figure 3-2. The routing table of the central router.



As a result, at the central router after some time (determined by the CDP packet distribution interval), records about networks connected to remote routers are added to the routing table. An example of the routing table of the central router is shown in Figure 3-2.

One additional entry appears on the remote routers - the default route to the central router. An example of the routing table of a remote router is shown in Figure 3-2.

The administrative distance in both cases is 160 by default.

The default metric is - 1 (which is quite logical, given that remote routers cannot be more than one hop away from the central one).

Figure 3-3. Routing table of the remote router.



In this case, only connected networks are transmitted to the central router. The networks described by static routing are not transmitted (and dynamic routing on remote routers cannot be enabled by definition). Attention should be paid to the fact that even when describing a static route, we will use the interface as the target of the route, not the gateway IP address, despite the fact that in the routing table this network described by the static route will be signed as directly connected ( Cisco routing tables, shown in Figure 3-4), it will not get into the list.

Figure 3-4. A static route that has an interface as a target, and not a gateway IP address, is displayed on the Cisco routers as a connected network.



As can be seen in Figure 3-5, only the networks connected to the nearest remote routers are present in the routing table of the central router R1, and the network 172.16.3.0/24 connected to R4 and described by R3 with a static route did not get into its routing table.

Figure 3-5. The routing table of the central router contains only “really connected” to the remote routers of the network.



Figure 3-6. If you disable the CDP protocol, then the ORD protocol will not work.



Naturally, since ODR requires CDP for its operation, disabling the latter causes routers to stop sharing route information. Figure 3-6 shows that if the remote router (in the example on R2) disables the CDP, it will stop transmitting the routing information (in fact, it will stop transmitting all the information that it previously transmitted using this protocol). As a result, on the central router, the timers of these networks will not be updated in the routing table, and after about 180 seconds the routes will be labeled as "possibly down", and after another 60 seconds they will disappear completely from the routing table.

Please note that routers do not consider these intervals to within a second; this would obviously be too resource intensive. The system has a timer that “ticks” in accordance with the message delivery interval, by default, once a minute. And the router simply counts three such “ticks” in order to understand that the CDP message was missed three times. And depending on the moment when the last CDP message was received regarding the nearest “tick”, we will get a delay of a little more than 180 seconds, or approaching 240 seconds.

This conclusion was obtained by studying the system response time to receiving CDP messages in conjunction with the ODR protocol, taking into account that both the operating system and these protocols are proprietary, closed, there is no information about exact processing algorithms. It may well be that on other versions of IOS everything will be different.

Do not despair, by and large this is not so important, but this implementation is very interesting, especially considering that the idea of ​​"ticks" is not unique and is used in many operating systems.

The remote router will also lose the default route entry, since it will ignore all CDP messages coming to it.

And of course, ODR does not have built-in security (encryption, digital signature), which does not affect its reputation very well and limits its scope.

')

4. ODR timers

Although the message delivery time is determined by the settings of the CDP, you can control the message processing timers with limited time using the timers basic command in the router configuration mode. But here it should be remembered that the control will not be complete, since the re-sending interval will depend only on the CDP setting and cannot be influenced by the timers basic command. It is important to understand that if you set too small values, without changing the CDP timers, this will lead to the periodic disappearance of routes from the routing table. You should also not set these values ​​too large, since then information about unreachable networks will be in the routing tables for too long.

As in other dynamic routing protocols, the parameters used at the moment, and in particular the protocol timers, can be viewed using the show ip protocols command. The output of this command is shown in Figure 4-1.

Figure 4-1. The output of the show ip protocols command for the ODR protocol.



To change the timers, use the timers basic command, the parameters of which are transmitted successively the values ​​of standard timers:

• Update
• Invalid
• Holddown
• Flush
• Sleep Time (optional)

When analyzing the output of the show ip protocols command, you can see that the Holddown timer is not applicable for the ODR, but since it is impossible to skip it using the timers basic syntax, you need to specify something, but the specified value will not affect anything.

It should also be noted that the period for sending messages is not governed by the Update parameter, but by the time settings of the CDP protocol (in general, you can read about the CDP protocol itself and its timers in particular in the course on this protocol). But unlike Holddown, which doesn’t affect anything at all, the Update value is used in a specific way, which will be shown below with an example.

For example, if we give the command timers basic 5 15 25 50 (instead of the third value, we could write any number), and without changing the properties of the CDP, the message distribution period will remain as before - one minute. This is easily seen when analyzing the traffic captured on the router interface shown in Figure 4-2.

Figure 4-2. Capturing CDP traffic, the default CDP frame broadcast interval is 1 minute.



For clarity, we will enable the CDP protocol debugging mode and the routing table processing ( debug cdp packets and debug ip routing ), and also disable the right (fa0 / 1) interface to monitor the traffic of only one interface.

Figure 4-3. Diagnostics of CDP and ODR protocol interaction using the debug command, stage 1.



Figure 4-3 shows that when a CDP packet is received from a neighbor, the received routes are added to the routing table (at 25 minutes 12 (almost 13) seconds according to the local time of the router).

Figure 4-4. Diagnostics of CDP and ODR protocol interaction using the debug command, stage 2.



After 19 seconds (Figure 4-4), the Invalid timer is triggered (we set the Invalid parameter to 15 in the timers basic command).

Here, the router also does not count seconds. Based on the results of the experiments, we can conclude the following: it starts the timer that “ticks” every few seconds, the duration of the tick is determined by the Update parameter. Then the system takes an integer amount of "ticks" included in the interval of Invalid, and waits until they pass. Considering that the tick timer is not synchronized with the arrival of CDP messages, it turns out that a little longer time actually passes from the moment of receiving the last CDP message to the triggering of the Invalid timer.

The system, without receiving updates, marks routes as “possibly down” - “possibly unreachable”. But at the same time, the router continues to successfully send packets to these networks.

Figure 4-5. Diagnostics of CDP and ODR protocol interaction using the debug command, stage 3.



After another 35 seconds, at 26 minutes 7 seconds (Figure 4-5) according to the local time of the router, the system still without receiving updates removes routes from the routing table. This triggers the Flush timer, which we set to 50 seconds (about 55 seconds passed since the last update, but here, as well as in the Invalid timer, the system counts not the seconds, but the timer ticks, in our case five seconds, from here and small discrepancy).

Figure 4-6. Diagnostics of CDP and ODR protocol interaction using the debug command, step 4.



And finally, having received the next CDP update, exactly in a minute (Figure 4-6) from the moment of receiving the previous one, the routes appear again in the routing table.

Thus, we can draw the following conclusions:

• The value of the Update parameter, which in other dynamic routing protocols affects the announcement distribution period, indirectly affects the calculation of the invalid and flush timers, and should not be less than the CDP announcement distribution timer, in order to exclude the premature deletion of routing information from the routing table
• The value of the Invalid parameter, works in the same way as in other dynamic routing protocols and determines the time period if after the expiration of which a certain network does not receive an update, it is marked as “possibly unattainable” (possibly down). Must be more than update, recommended three times, so that even if three consecutive updates are lost, since they are transmitted without a delivery guarantee, the route is not considered unattainable.
• The value of the Flush parameter works in the same way as in other dynamic routing protocols and determines the time period if after the expiration of which a certain network does not receive an update, it is considered unreachable and is deleted from the routing table. Must be more than invalid, at least one interval of the update period.

The default timers basic values ​​are:

• update: 60
• invalid: 180
• holddown: 0
• flush: 240
• sleeptime: 0

5. Filtering routes in ODR

In some cases, there may be a situation in which for some time it will be necessary to exclude a specific network belonging to remote routers from the routing table of the central router.

This can be done, for example, by disabling the interface or CDP protocol on the corresponding device, but in this case we completely stop communicating with this device or lose all networks connected to it.

If it is necessary to remove from the routing table only one network from several that are accessible through a redistributed remote router, such cardinal methods are not suitable. In this case, you can use the distribute-list command, with which you can control the filtering of routes that are received or sent in announcements.

Figure 5-1. The routing table of the central router at the beginning of the experiment, it contains all the networks connected to remote routers.



For example, we want to temporarily exclude from the routing table one of the networks connected to router R2, namely the network 172.16.1.0/24. Figure 5-1 shows the networks present in the routing table of the central router at the beginning of the experiment.

The distribute-list command requires a pre-configured access list with described networks that can and cannot be received or transmitted in announcements.

ACL - Access Control List, in this course we will not discuss in detail the syntax and features of the use of access lists, you can read about them in more detail in the course on the configuration of security on Cisco devices).

Figure 5-2. Create ACL.



Creating an access list is shown in Figure 5-2 and is done using the access-list command. In it, we configure that we will ignore ads falling within the 172.16.1.0/24 range, and will accept all other ads.

Figure 5-3. Reconciling the created ACL with the distribute-list command.



After creating the sheet, you need to apply the distribute-list in ODR configuration mode, as shown in Figure 5-3. You must specify the direction - in (incoming announcements), and also, if necessary, you can specify the interface for which this filter will be applied. If the interface is not specified, then filtering will occur for all ads coming to all interfaces.

Figure 5-4. The routing table of the central router after applying the distribute-list command.



After that, the router stops processing incoming announcements about the network 172.16.1.0/24, and when the Flush timer comes, it disappears from the routing table, as shown in Figure 5-4.

The distribute-list command also has an out parameter, the use of which is to filter network entries for outgoing announcements, but it does not work for ODR. Actually, the central router sends only the default route, so there’s really nothing to filter.

6. Interworking with other routing protocols.

It makes sense to talk about the interaction of the ODR protocol with other dynamic routing protocols only in terms of transferring data about networks connected to remote routers (in the context of ODR) to another protocol, but not vice versa.

Configuring the transmission of routing information from an ODR occurs in the dynamic routing protocol that is to receive the routing information using the redistribute command . As parameters, you must pass the name of the protocol whose routes you want to import, in our case odr , as well as the subnets parameter, if there are subnets of class networks in the network.

The application of this command is shown in Figure 6-1. In the OSPF protocol configuration mode, the redistribute odr subnets command is issued , which causes the networks learned by the central router to be imported using OSPF protocol to their base using the ODR protocol and transferred further to the part of the network that is served by the OSPF protocol. Figure 6-1 shows the routing table of router R4, which received information about networks 172.16.0.0/24 and 172.16.2.0/24 from router R1 via the OSPF protocol, but since these networks were first studied by ODR and then imported from it into OSPF, this routing information is “non-native” for OSPF and the corresponding routes in the routing table are marked with “E2” symbols - external routes.

Please note that transmitting data in the opposite direction does not make sense. Route information collected by OSPF on the central router is already available, since this protocol is running on it. And remote routers, in any case, receive only default routes. Therefore, it does not make sense to apply the redistribute command to the ODR protocol (although this command is present in its configuration), therefore, there is no redistribute command in the configuration example in Figure 6-1 in the ODR configuration.

Figure 6-1. Apply the redistribute command to the OSPF protocol.



The example also leaves the filter applied to the ODR, which excludes the 172.16.1.0/24 network from processing, and as a result, only the 172.16.0.0/24 and 172.16.2.0/24 networks on the R4 router were transferred to OSPF.

If necessary, you can also define a redistribution filter in OSPF by applying route maps to the redistribute command, you can read about them in the course on routing optimization.

Configuring routing information to other internal routing protocols, such as RIP and EIGRP, is done in a similar way.

7. Additional ODR Setup

In addition to setting timers, filtering routes, and interacting with other routing protocols for ODR, several other configuration commands are applicable:

• maximum-paths — changes the number of routes installed in the routing table when there are multiple paths. The default value is four. It can be changed in the range from 1 to 6.

Figure 7-1. ORD supports load balancing.



Considering that the metrics of all routes will be equal to one, we cannot talk about balancing along routes with different costs. A network and an example of a routing table with several possible options for achieving one network is shown in Figure 7-1.If you give the maximum-paths 1 command in the ORD protocol configuration mode , the load balancing feature will be disabled and the routing table will have one path that was previously studied, as shown in Figure 7-2.

Figure 7-2. Disabling load balancing by setting the maximum-paths value to one.



If the number of routes is greater than the permissible limit, those that were previously studied fall into the routing table.

• Distance - changes the administrative distance.

Figure 7-3. Change the administrative distance for the ODR protocol.



Given that administrative distance is not transmitted in CDP messages, the configuration is local only for the central router, you cannot change the administrative distance on remote routers (the distance command is given in router configuration mode, and the router odr command on remote routers cannot be given, because they will go into central mode, stop sending information about their networks, and ignore messages from the “real” central router). An example of a change in administrative distance is shown in Figure 7-3.

• default – - . no .

• passive-interface – .
• redistribute – , , -
• network – .
• neighbor – , CDP , .
• default-metric – , , .

8. .

And so, for those who read to the end, you can summarize the protocol ODR:

• It works only on Cisco devices, as it is proprietary.
• It works on top of the CDP protocol and practically does not load lines with additional traffic.
• Works only in the star topology (“hub-and-spoke”).
• Requires minimal configuration — enabled by the router odr command on the central router.
• A prerequisite for work is the absence of other dynamic routing protocols on remote routers.
• It processes only connected routes, static routes are not processed.
• No built-in security.
• Possibly limited route mapping management.
• Studied networks can be transferred to other routing protocols.
• Timer management may also require changing the settings of the CDP protocol.

Frankly, in view of the fact that at least some configuration is required for remote routers, the appropriateness of using the ODR protocol in modern networks is highly questionable. Especially given its weak functionality. But, nevertheless, it is certainly possible to find a scope for this protocol.

On the other hand, this protocol is an interesting, academic example of a non-standard approach to implementing a dynamic routing protocol.



EIGRP, OSPF, IPV6 and BGP are on the way.