EIGRP Packet Format

EIGRP has 5 Packets Types (Hello, Update, Query, Reply, ACK). Each of these packets have a common header fields of which are shown below.

  • Version:  This field specifies different versions of EIGRP. Version 2 of EIGRP was implemented beginning with Cisco IOS Software Releases 10.3(11), 11.0(8), and 11.1(3). EIGRP Version 2 is the most recent version that contains many enhancements to improve the stability and scalability of EIGRP.
  • OPCode: This field specifies the types of EIGRP packet contained. OPCode 1 is the Update packet, OPCode  3 is the Query packet, OPCode 4 is the Reply Packet, and OPCode 5 is the EIGRP Hello packet and ACK Packet.
  • Checksum: This field is used as the regular IP checksum, calculated based on the entire EIGRP packet, excluding the IP header.
  • Flags: This field involves only two flags now. The flag indicates either an init for new neighbor relationship or the conditional receive for EIGRP RTP.
  • Sequence: Specifies the sequence number used by the EIGRP RTP.
  • Acknowledgment: Used to acknowledge the receipt of an EIGRP reliable packet.
  • Autonomous System Number: AS Number field specifies the number for the identification of EIGRP domain.
EIGRP packets might also contain some TLVs (Type, Length, Value). These TLVs are placed after the AS number Field. The TLV triplets carry route entries, as well as provide the fields for DUAL process management. Some of common TLVs are listed below:
  • a TLV to carry K parameters (seen in Hello packet)
  • a TLV to carry IP internal routes (seen in Update packet)
  • a TLV to carry IP External routes (seen in Update packet)
EIGRP Parameters TLV:


Wireshark Capture of Parameters TLV:


EIGRP IP Internal Route TLV:


  • Next hop: This field specifies the IP address of the next hop to which packets should be forwarded.
  • Delay:  This field specifies the Delay parameter of the route metric. The delay value is the sum of all the delay parameters on the interface across the path to the destination network.
  • Bandwidth: This field specifies the Bandwidth parameter of the route metric. The bandwidth is obtained from the interface, and it is the lowest bandwidth on the interface across the path to the destination network.
  • MTU: This field specifies the interface MTU parameter of the route metric.
  • Hop count: This field specifies the number of hops to the destination network.
  • Reliability: This field specifies the reliability of the interface, out of a possible range of 1 to 255. A reliability of 1 indicates that the reliability is 1/255, whereas a reliability of 255 indicates that the interface is 100 percent reliable.
  • Load: This field specifies the load of the interface, out of a possible range of 1 to 255. A load value of 1 indicates that the interface has a very light load, while a load value of 255 indicates that the interface is highly saturated.
  • Prefix length: This field specifies the subnet mask of the destination network.
  • Originating router: This field specifies the router ID of the router that originates the external EIGRP routes.
  • Originating autonomous system number: This field specifies the EIGRP autonomous system number of the routes before getting redistributed into this EIGRP autonomous number.
  • External protocol metric: This field specifies the metric of the routes before getting redistributed into EIGRP.
  • External protocol ID: This field specifies the type of routing protocol that originates the routes that were redistributed into EIGRP. The routing protocol type can be BGP, OSPF, RIP, IGRP, and so forth.
Wireshark Capture of EIGRP IP Internal Route TLV:


If you understood the concept and like this article, kindly share the same with your friends.
continue reading EIGRP Packet Format

EIGRP Graceful Shutdown - Goodbye Message

EIGRP Graceful shutdown is designed to improve EIGRP network convergence and it uses Goodbye message to communicate this information to the neighbors.


Let's try to understand the concept using above topology.

If R1 has to go down for some maintenance, R2 would have to wait for its hold timer to expire before it would discover the change and react to it.Packets sent during this time would be lost.

With graceful shutdown feature in EIGRP, a Goodbye message is multicast when an EIGRP routing process is shut down, to inform adjacent peers about this topology change. This feature allows supporting EIGRP peers to synchronize and recalculate neighbor relationships more efficiently than would occur if the peers discovered the topology change after the hold timer expired. The Goodbye message is supported in Cisco IOS Software Release 12.3(2), 12.3(3)B, and 12.3(2)T and later.

In above lab simulation, I have used 12.4 IOS version.

To simulate the generation of Goodbye message, I have removed the network command on R1 and we can see that a Goodbye message is received on R2.

R1(config)# router eigrp 10
R1(config-router)#no network 10.0.0.0

R2#
*Mar  1 00:05:18.111: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 10.10.12.1 (FastEthernet0/0) is down: Interface Goodbye received

Imp Note: Goodbye messages are sent in hello packets. EIGRP sends an interface goodbye message with all K values set to 255 when taking down all peers on an interface.


A Cisco router that runs IOS release (12.2 for example) that does not support the Goodbye message will not be able interpret the message as a K-value mismatch and therefore display the following message:

*Mar  1 00:08:18.411: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.10.12.1 (FastEthernet0/0) is down: K-value mismatch

The receipt of a goodbye message by a non-supporting neighbor does not disrupt normal network operation of EIGRP. The non-supporting neighbor will terminate the session when the hold timer expires. The sending and receiving routers will re-converge normally after the sender reloads.

An EIGRP router will send a Goodbye message on an interface if the network command (under the EIGRP process) that encompasses the network on that interface is removed (with 'no network' router  config command). An EIGRP router sends a goodbye message on all interfaces if the EIGRP process is shut down (with 'no router eigrp AS Number' global config command). However, an EIGRP router will not send a Goodbye message if an interface is shut down or the router is reloaded.

If you understood the concept and like this article, kindly share the same with your friends.
continue reading EIGRP Graceful Shutdown - Goodbye Message

EIGRP Packet Types

EIGRP (Protocol No. 88) runs on top of IP and hence is referred to as a Transport layer protocol.

The Application layer protocols such as BGP, Telnet, FTP etc, do not have any inbuilt reliability mechanism and therefore depend on TCP (Protocol No. 6) at Transport layer to maintain reliability.

EIGRP uses 5 packet types (Hello, Update, Query, Reply, ACK) for functioning. Each EIGRP Packet has a common header and some TLVs associated with it. Kindly refer EIGRP Packet Format for more details.

The EIGRP packets carrying routing information (i.e. Update, Query, and Reply) are sent reliably because they are not sent periodically, which means that a sequenc.e number is assigned to each reliable packet and an explicit acknowledgment is required for that sequence number.

EIGRP has its own reliability mechanism to acknowledge the receipt of its multiple types of packets and uses Reliable Transport Protocol (RTP) to deliver or exchange packets between the neighbors in guaranteed and ordered way.

RTP ensures that ongoing communication is maintained between neighboring routers. As such,
a re-transmission list is maintained for each neighbor. This list indicates packets not yet acknowledged
by a neighbor within the RTO(Round-Trip Timed Out). It is used to track all the reliable packets that were sent but not acknowledged.

Imp Note: If the RTO expires before an ACK packet is received, the EIGRP process transmits another copy of the reliable packet, up to a maximum of 16 times or until the hold time expires.

Following are five types of packets and details are shared in table below:


Let's see some details of each packet using below topology.


Details of Hello Packet:

EIGRP Hello/Holdown timers/Intervals:
  • For the links with bandwidth greater than T1(1.544 Mbps) or more, for example, Ethernet, Fast-Ethernet, POS links, hello packets are sent every 5 seconds and hold down timer is 15 seconds.
  • For the links with bandwidth equal to or less than T1, hello timer is 60 seconds and default hold timer is 180 seconds.
Hello Packets have Acknowledgment number of 0. Both Hello and ACK Packets have Opcode 5.

Hello Packets are always sent to a destination multicast IP address 224.0.0.10 reserved for EIGRP.  At Data Link layer, a specific EIGRP destination MAC address (01:00:5e:00:00:0a) is used as shown in figure below:


Also note that default Hello and Hold down timer can be changed using interface configuration commands as given below:

R1(config-if)#ip hello-interval eigrp as-number seconds.
R1(config-if)#ip hold-time eigrp as-number seconds

Details of Update Packet:

EIGRP Updates Packets are sent as multicast as well unicast as explained below:

EIGRP Updates Packets are sent multicast when a new route is discovered, a network goes unreachable or any routing change, for example, a metric change happens. To understand this, let's configure a new loopback interface Lo1 (10.10.0.100/32) on R1 and advertise this subnet in EIGRP. We'll see that R1 will send an EIGRP Update of this subnet on multicast destination IP address 224.0.0.10  to its neighbor R2. Below is Wireshark capture of R1 sending an update to R2 on multicast address 224.0.0.10. Update messages have OPCode of 1.


EIGRP Update Packets are sent as  unicast to neighbors when EIGRP process is restarting. For example, if we reset the EIGRP process on R1 using "clear ip eigrp neighbor" command, R1 and R2 will send the Update Packet to each other as unicast messages on their physical interface IP addresses. R1's physical interface IP address is 10.10.12.1/24 and R2's physical interface IP address is 10.10.12.2/24.

R1#clear ip eigrp neighbors

Below is wireshark capture of R1 sending unicast update to R2.


Details of Query Packet:

When an EIGRP router doesn't have a feasible successor (FS) for a route, it sends Query Packet to its neighbors. This query Packet is sent as a multicast on a multicast address 224.0.0.10

If the router which has originated the Query Packet does not receive a response/Reply Packet from any of its neighbors, it re-sends the Query as a Unicast packet to the non-responsive neighbor(s). If no response is received in 16 attempts, the EIGRP neighbor relationship is reset with that neighbor.

Query Packets are sent reliably and neighbors reply with EIGRP ACK Packet as soon they receive the Query Packet to confirm the receipt. Query Packets have OPCode of 3.

Details of Reply Packet:

Reply Packets are sent as unicast on physical interface IP address of the neighbor and are sent reliably, meaning that the neighbors reply with EIGRP ACK Packet as soon they receive the Reply Packet to confirm the receipt. Reply Packets have OPCode of 4.

Details of ACK Packet:

EIGRP ACK Packets are sent unicast as an acknowledgement for receipt of Update, Query, and Reply Packets. EIGRP ACK Packets are Hello Packets with a non-zero Ack number.  Both Ack and Hello Packets have Opcode 5.


We can also see the flow of EIGRP messages by enabling debugging of EIGRP packets as shown below:

R1#debug eigrp packets
    (UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
EIGRP Packet debugging is on



If you understood the concept and like this article, kindly share the same with your friends.






continue reading EIGRP Packet Types

BGP Redistribute-Internal

By default, iBGP routes do not get redistributed into OSPF or ISIS. We need to add 'bgp redistribute-internal' under BGP router configuration to enable the BGP internal routes get redistributed in OSPF or ISIS.


Scenario 1:  If we do not configure 'bgp redistribute-internal' command  under BGP, we will not see the route for 10.10.0.1/32 on R3.

R3#show ip route 10.10.0.1
% Subnet not in table


Scenario 2:  After adding the 'bgp redistribute-internal' command under BGP, we will see the route for 10.10.0.1/32 on R3.

R2(config-if)#router bgp 100
R2(config-router)#bgp redistribute-internal


R3#show ip route 10.10.0.1
Routing entry for 10.10.0.1/32
  Known via "ospf 1", distance 110, metric 1, type extern 2, forward metric 1
  Last update from 10.10.23.2 on FastEthernet1/0, 00:00:03 ago
  Routing Descriptor Blocks:
  * 10.10.23.2, from 10.10.0.2, 00:00:03 ago, via FastEthernet1/0
      Route metric is 1, traffic share count is 1


Or if we were running ISIS between R2-R3

R3#show ip route 10.10.0.1
Routing entry for 10.10.0.1/32
  Known via "isis", distance 115, metric 10, type level-2
  Redistributing via isis
  Last update from 10.10.23.2 on FastEthernet1/0, 00:00:03 ago
  Routing Descriptor Blocks:
  * 10.10.23.2, from 10.10.23.2, 00:00:03 ago, via FastEthernet1/0
      Route metric is 10, traffic share count is 1


If you understood the concept and like this article, kindly share the same with your friends.
continue reading BGP Redistribute-Internal

Route Redistribution in ISIS

Redistribution is technique using which the boundary routers connecting different routing domains can exchange and advertise routing information. In this article we will learn how to redistribute any routing protocol into ISIS. Below syntax is followed. The command has to be configured in router configuration mode.

redistribute protocol [process-id] [level  level-value] [metric metric-value] [metric-type type-value]  [route-map name]

Description:
  • protocol: For example the protocol you want to redistribute into ISIS (i.e. EIGRP, OSPF,  RIP, or BGP etc.)
  • process-id: This field is specifically used while redistributing the protocols EIGRP and BGP into ISIS. The value of this field is AS number in case of EIGRP and BGP and process-id in case of OSPF. No value is required for RIP.
  • level: This is an optional field. It specifies how external routes are redistributed. The level types exist. The routers can be Level 1 (level-1), Level 1/Level 2 (level-1-2), or Level 2 (level-2) routes. The default type is level-2.
  • metric: This is an optional field  that specifies the ISIS seed metric used for the redistributed route. IS-IS uses a default metric of 0. Unlike RIP and EIGRP, a default metric of 0 is not treated as infinity or unreachable, so the route is redistributed. The metric is incremented as the route is propagated into the IS-IS domain. The IS-IS default metric value is cost.
  • metric-type: This field is optional and specifies the the IS-IS metric type as external or internal. The default metric type is internal.
  • route-map: This is again an optional field and used when when we have to do any route filtering while redistribution.

R2(config)#router ISIS
R2(config-router)#redistribute eigrp 10 route-map FILTER

Imp Point: Kindly also note that you have to configure the the route-map 'FILTER'. An empty route-map or wrong route-map configured will not allow redistribution of routes.

Using above topology, let's try a simple redistribution of EIGRP into ISIS. While checking the ISIS database for R1's prefix 10.10.0.1/32, we can see the route is installed with default seed metric of 0.

R2(config)#router ISIS
R2(config-router)#redistribute eigrp 10 level-2

R2#sh isis database level-2 R2.00-00 detail
IS-IS Level-2 LSP R2.00-00
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime      ATT/P/OL
R2.00-00            * 0x00000008   0x8BFD        725               0/0/0
  Area Address: 49.00aa
  NLPID:        0xCC
  Hostname: R2
  IP Address:   10.10.23.2
  Metric: 10         IS R3.02
  Metric: 0          IP-External 10.10.0.1 255.255.255.255
  Metric: 0          IP-External 10.10.0.2 255.255.255.255
  Metric: 0          IP-External 10.10.12.0 255.255.255.0
  Metric: 10         IP 10.10.23.0 255.255.255.0

Imp Point:  The default link cost of any link in ISIS domain is 10 (irrespective of link bandwidth) when the ISIS is configured with metric-style  narrow (0-63).

If we check the route of prefix 10.10.0.1/32 on R3, the link cost metric will be added to default seed metric(0). This metric is cumulative and keep on adding as the route propagates more links in the network.

R3#show ip route 10.10.0.1
Routing entry for 10.10.0.1/32
  Known via "isis", distance 115, metric 10, type level-2
  Redistributing via isis
  Last update from 10.10.23.2 on FastEthernet1/0, 00:05:53 ago
  Routing Descriptor Blocks:
  * 10.10.23.2, from 10.10.23.2, 00:05:53 ago, via FastEthernet1/0
      Route metric is 10, traffic share count is 1


When ISIS routes are redistribued in other protocols for example EIGRP or OSPF, we have the option to include Level 1, Level 2, or both Level 1 and Level 2 routes.  If no level is specified during redistribution, all routes are redistributed.

R2(config)#router eigrp 10
R2(config-router)#redistribute isis ?
  WORD       ISO routing area tag
  level-1    IS-IS level-1 routes only
  level-1-2  IS-IS level-1 and level-2 routes
  level-2    IS-IS level-2 routes only
  metric     Metric for redistributed routes
  route-map  Route map reference
  <cr>

R2(config-router)#redistribute isis metric 10000 10 255 1 1500

As specified above, we didn't choose any level type while redistributing ISIS routes in EIGRP, so all routes are distributed by default.

R1#sh ip route eigrp
D        10.10.0.2/32 [90/156160] via 10.10.12.2, 00:22:33, FastEthernet1/0
D EX     10.10.0.3/32 [170/261120] via 10.10.12.2, 00:01:56, FastEthernet1/0
D        10.10.23.0/24 [90/30720] via 10.10.12.2, 00:22:33, FastEthernet1/0


If you want to restrict the number of  redistributed, you can use the below router configuration command in ISIS.

R2(config)#router isis
R2(config-router)#redistribute maximum-prefix maximum [threshold] [warning-only | withdraw]

By default, we will a logging warning when a threshold of 75%  of  defined maximum value is reached.  Also, after reaching the defined maximum number, no further routes are redistributed. The optional withdraw field will also cause IS-IS to rebuild link-state protocol data units (PDUs) (link-state packets [LSPs]) without the external (redistributed) IP prefixes. If the warning-only field is configured, no limitation is placed on redistribution; the maximum value number simply becomes a second point where another warning messaged is logged.

Imp Point: By default, iBGP routes do not get redistributed into ISIS (or OSPF). We need to add bgp redistribute-internal command under BGP router configuration to enable the BGP internal routes get redistributed in ISIS (or OSPF).


If you understood the concept and like this article, kindly share the same with your friends.

continue reading Route Redistribution in ISIS

Route Redistribution in EIGRP

Redistribution is technique using which the boundary routers connecting different routing domains can exchange and advertise routing information. In this article we will learn how to redistribute any routing protocol into EIGRP. Below syntax is followed. The command has to be configured in router configuration mode.

redistribute protocol [process-id] [metric metric-value] [match route-type] [route-map name]

Description:
  • protocol: For example the protocol you want to redistribute into EIGRP (i.e. OSPF, RIP, or BGP etc.)
  • process-id: This field is specifically used while redistributing the protocols OSPF and BGP into EIGRP. The value of this field is AS number in case of BGP and  process-id in case of OSPF. This field is not required for RIP and ISIS.
  • metric: This is an optional field  that specifies the EIGRP seed metric, in the fixed order of bandwidth, delay, reliability, load, and maximum transmission unit (MTU), for the route going to be redistributed. When redistributing other protocol routes into EIGRP (other than ISIS), if this metric value is not specified and  also if no value is specified using the 'default-metric' router configuration command, the default metric is 0. The routes will not be redistributed because like RIP, EIGRP also considers the 0 metric as infinity. In EIGRP, the metric is calculated based only on bandwidth and delay by default.
  • match/route-type: This is an optional field and specifically used while redistributing OSPF into RIP. Three types of routes exist in OSPF namely Internal (that are internal to an OSPF domain), External type-1, External type 2, or NSSA-External.
  • route-map: This is again an optional field and used when when we have to do any route filtering while redistribution.
Imp Point: When redistributing routes from other routing protocols into EIRGP, the routes are denoted by D EX and the Administrative Distance (AD) of the redistributed routes 170 compared to internal EIGRP routes that are denoted by D and have AD value of 90. Because of their higher AD, EIGRP external routes are less preferred than EIGRP internal routes.


R2(config)#router eigrp 10
R2(config-router)#redistribute ospf 1 metric 10000  100  255  1  1500 route-map FILTER

Imp Point: Kindly also note that you have to configure the the route-map 'FILTER'. An empty route-map or wrong route-map configured will not allow redistribution of routes.

Below is description of EIGRP metric fields:


Using above topology given in beginning of the this article, let's try a simple redistribution of OSPF into EIGRP.

R2(config)#router eigrp 10
R2(config-router)#redistribute ospf 1 metric 10000  100  255  1  1500

Or if you don't want to specify metric specifically while redistributing OSPF but a general reference value for all protocols, we can explicitly use 'default-metric' router configuration command to specify the metric.

R2(config)#router eigrp 10
R2(config-router)#redistribute ospf 1 
R2(config-router)#default-metric 10000  100  255  1  1500


If you understood the concept and like this article, kindly share the same with your friends.

continue reading Route Redistribution in EIGRP

Route Redistribution in OSPF

Redistribution is technique using which the boundary routers connecting different routing domains can exchange and advertise routing information. In this article we will learn how to redistribute any routing protocol into OSPF. Below syntax is followed. The command has to be configured in router configuration mode.

redistribute protocol [process-id] [metric metric-value] [metric-type type-value] [route-map name] [subnets] [tag tag-value]

Description:
  • protocol: For example the protocol you want to redistribute into OSPF (i.e. EIGRP, RIP, or BGP etc.)
  • process-id: This field is specifically used while redistributing the protocols EIGRP and BGP into OSPF. The value of this field is AS number in case of EIGRP and BGP and process-id in case of OSPF.
  • metric: This is an optional field  that specifies the OSPF seed metric used for the redistributed route. When redistributing any protocol into OSPF, the default metric is 20 (except for BGP routes, which have a default metric of 1).
  • metric-type: This field is optional and specifies the external link type associated with the external route advertised into the OSPF routing domain. This value can be 1 for type 1 external routes or 2 for type 2 external routes. The default is 2 or E2 route type.
  • route-map: This is again an optional field and used when when we have to do any route filtering while redistribution.
  • subnets: This is an optional field. This field specifies that subnetted routes should also be redistributed into OSPF. Only routes that are not subnetted are redistributed if the subnets keyword is not specified.
  • tag: It is again an optional 32 bit field with a  decimal value attached to each external route. The OSPF protocol itself does not use this parameter; it may be used to communicate information between OSPF autonomous system boundary routers (ASBRs).
Imp Point: When redistributing routes from other routing protocols into OSPF, the default metric is 20, the default metric-type is 2, and subnets (subnetted routes) are not redistributed by default.


R2(config)#router ospf 1
R2(config-router)#redistribute eigrp 10 subnets route-map FILTER

Imp Point: Kindly also note that you have to configure the the route-map 'FILTER'. An empty route-map or wrong route-map configured will not allow redistribution of routes.

Using above topology, let's try a simple redistribution of EIGRP into OSPF.

R2(config)#router ospf 1
R2(config-router)#redistribute eigrp 10 subnets

When the route is redistributed into OSPF as type-1 (or E1), internal OSPF link costs are also added.  In above topology R2-R3 link cost is 10,  R1's Lo0 prefix 10.10.0.1/32 is redistributed with default seed metric of 20. While we check the route of prefix 10.10.0.1/32 on R3, total OSPF metric shows 30 (20+10).

R2(config)#router ospf 1
R2(config-router)#redistribute eigrp 10 subnets metric-type 1

R3# show ip route 10.10.0.1
Routing entry for 10.10.0.1/32
  Known via "ospf 1", distance 110, metric 30, type extern 1
  Last update from 10.10.23.2 on FastEthernet1/0, 00:00:04 ago
  Routing Descriptor Blocks:
  * 10.10.23.2, from 10.10.0.2, 00:00:04 ago, via FastEthernet1/0
      Route metric is 30, traffic share count is 1

When the route is redistributed into OSPF as type-2 (or E2), internal OSPF link costs are not added and route is propagated with default seed metric of 20.  In above topology R2-R3 link cost is 10,  R1's Lo0 prefix 10.10.0.1/32 is redistributed with default seed metric of 20. While we check the route of prefix 10.10.0.1/32 on R3, total OSPF metric shows 20 (Internal OSPF link costs are not added).

R2(config)#router ospf 1
R2(config-router)#redistribute eigrp 10 subnets metric-type 1

R3# sh ip route 10.10.0.1
Routing entry for 10.10.0.1/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10
  Last update from 10.10.23.2 on FastEthernet1/0, 00:00:03 ago
  Routing Descriptor Blocks:
  * 10.10.23.2, from 10.10.0.2, 00:00:03 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1


When ISIS routes are redistribued in OSPF, we have the option to include Level 1, Level 2, or both Level 1 and Level 2 routes.  If no level is specified during redistribution, all routes are redistributed.

R2(config)#router OSPF 1
R2(config-router)#redistribute isis ?
  WORD       ISO routing area tag
  level-1    IS-IS level-1 routes only
  level-1-2  IS-IS level-1 and level-2 routes
  level-2    IS-IS level-2 routes only
  metric     Metric for redistributed routes
  route-map  Route map reference
  <cr>

R2(config-router)#redistribute isis subnets

R1#show ip route 10.10.0.3
Routing entry for 10.10.0.3/32
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1
  Last update from 10.10.12.2 on FastEthernet1/0, 00:00:01 ago
  Routing Descriptor Blocks:
  * 10.10.12.2, from 10.10.0.2, 00:00:01 ago, via FastEthernet1/0
      Route metric is 20, traffic share count is 1

As specified above, we didn't choose any level type while redistributing ISIS routes in OSPF, so all routes are distributed by default.


If you want to restrict the number of  redistributed, you can use the below router configuration command in OSPF.

R2(config)#router ospf 1
R2(config-router)#redistribute maximum-prefix maximum [threshold] [warning-only]

By default, we will a logging warning when a threshold of 75%  of  defined maximum value is reached.  Also, after reaching the defined maximum number, no further routes are redistributed. If the warning-only keyword is also configured, no limitation is placed on redistribution and the maximum value number simply becomes a second point where another warning messaged is logged.


Redistributing iBGP into OSPF

By default, iBGP routes are not redistribute into OSPF. We need to add  bgp redistribute-internal command under BGP router configuration.

Without adding the 'bgp redistribute-internal' command  under BGP, we will not see the route for 10.10.0.1/32 on R3.

R3#show ip route 10.10.0.1
% Subnet not in table


After adding the 'bgp redistribute-internal' command under BGP, we will see the route for 10.10.0.1/32 on R3.

R2(config-if)#router bgp 100
R2(config-router)#bgp redistribute-internal


R3#show ip route 10.10.0.1
Routing entry for 10.10.0.1/32
  Known via "ospf 1", distance 110, metric 1, type extern 2, forward metric 1
  Last update from 10.10.23.2 on FastEthernet1/0, 00:00:03 ago
  Routing Descriptor Blocks:
  * 10.10.23.2, from 10.10.0.2, 00:00:03 ago, via FastEthernet1/0
      Route metric is 1, traffic share count is 1


If you understood the concept and like this article, kindly share the same with your friends.

continue reading Route Redistribution in OSPF

Route Redistribution in RIP

Redistribution is technique using which the boundary routers connecting different routing domains can exchange and advertise routing information. In this article we will learn how to redistribute any routing protocol into RIP. Below syntax is followed. The command has to be configured in router configuration mode.

redistribute protocol [process-id] [match route-type] [metric metric-value] [route-map name]

Description:
  • protocol: For example the protocol you want to redistribute into RIP (i.e. EIGRP, OSPF, or BGP etc)
  • process-id: This field is specifically used while redistributing the protocols EIGRP and OSPF into RIP. The value of this field is AS number in case of EIGRP and process-id in case of OSPF.
  • match/route-type: This is an optional field and specifically used while redistributing OSPF into RIP. Three types of routes exist in OSPF namely Internal (that are internal to an OSPF domain), External type-1, External type 2, or NSSA-External.
  • metric: This field is optional. This field specifies the metric with which the route will be imported in RIP. We must specify a value because default seed metric for RIP is 0 which is considered to be infinity and route is not redistributed. We can also use 'default-metric' router configuration command to specify the reference metric used for redistribution.
  • route-map: This is again an optional field and used when when we have to do any route filtering while redistribution.
R2(config)#router rip
R2(config-router)#redistribute ospf 1 metric 3 match external 1 route-map FILTER

Or if you don't want to specify metric specifically while redistributing OSPF but a general reference value for all protocols, we can explicitly use 'default-metric' router configuration command to specify the metric.

R2(config)#router rip
R2(config-router)#redistribute ospf 1 match external 1  route-map FILTER
R2(config-router)#default-metric 3

Imp Point: Kindly also note that you have to configure the the route-map 'FILTER'. An empty route-map or wrong route-map configured will not allow redistribution of routes.

Using above topology, let's try a simple redistribution of OSPF into RIP.

R2(config)#router rip
R2(config-router)#redistribute ospf 1 metric 3

Taking a reference to above topology, while we redistribute OSPF into RIP on R2, we use the metric value of 3. When R3 receives the redistributed routes(for example R1's Lo0 10.10.0.1/32), it will not add an extra hop to the metric as a general behavior of a router running RIP (Metric/hop count gets increased with 1 while the update of a prefix is received on inbound interface). Kindly see the output below:

R3#sh ip route 10.10.0.1
Routing entry for 10.10.0.1/32
  Known via "rip", distance 120, metric 3
  Redistributing via rip
  Last update from 10.10.23.2 on FastEthernet1/0, 00:00:23 ago
  Routing Descriptor Blocks:
  * 10.10.23.2, from 10.10.23.2, 00:00:23 ago, via FastEthernet1/0
      Route metric is 3, traffic share count is 1

Imp Point: Kindly also note that there is an exception while we redistribute a static/default route (using redistribute static) or a connected route (redistribute connected)  in RIP the default seed metric is 1 and not infinity. For example we have created a new loopback on R1 (10.10.1.100/32) and instead of advertising it in OSPF, we have put a static route on R2 towards R1. Below is the config on R2.

R2(config)#ip route 10.10.0.100 255.255.255.255 10.10.12.1

R2#sh run | section  router rip
router rip
 version 2
 redistribute static
 redistribute ospf 1 metric 3
 network 10.0.0.0
 no auto-summary


We have not put any metric command while redistributing the static route, neither we have put the default-metric command explicitly under RIP process.  Below is the output of prefix 10.10.0.100/32 learned with metric 1.

R3#show ip route 10.10.0.100
Routing entry for 10.10.0.100/32
  Known via "rip", distance 120, metric 1
  Redistributing via rip
  Last update from 10.10.23.2 on FastEthernet1/0, 00:00:03 ago
  Routing Descriptor Blocks:
  * 10.10.23.2, from 10.10.23.2, 00:00:03 ago, via FastEthernet1/0
      Route metric is 1, traffic share count is 1

While we redistribute connected routes (using 'redistribute connected' command) in RIP on R2, the routes(for example R2's loopback and connected links) will be redistributed with metric 1 .

R2(config)#router rip
R2(config-router)#redistribute connected


Let's check the route of R2's Lo0 prefix 10.10.0.2/32 on R3

R3#show ip route 10.10.0.2
Routing entry for 10.10.0.2/32
  Known via "rip", distance 120, metric 1
  Redistributing via rip
  Last update from 10.10.23.2 on FastEthernet1/0, 00:00:14 ago
  Routing Descriptor Blocks:
  * 10.10.23.2, from 10.10.23.2, 00:00:14 ago, via FastEthernet1/0
      Route metric is 1, traffic share count is 1


If you understood the concept and like this article, kindly share the same with your friends.

continue reading Route Redistribution in RIP