BGP States

BGP goes through the following stages.


Let's understand all the states in detail with help of a simple 2 routers topology.


Idle:  In this stage the router is searching the routing table to see whether a route exists to reach the
neighbor.

Below is the output for R1 in Idle state because R1 doesn't have route to R2's neighbor address (Lo0)

R1#show ip bgp summary | include   10.10.0.2
10.10.0.2       4          100       0       0        1    0    0  never    Idle

R1#sh ip route 10.10.0.2
% Subnet not in table

Connect:  If the router found a route to the neighbor address, BGP peer moves to connect state, initiates a Connect Retry Timer (default value 120 seconds) begins the Three-Way TCP handshake process.

R1#sh ip route 10.10.0.2
Routing entry for 10.10.0.2/32
  Known via "ospf 1", distance 110, metric 2, type intra area
  Last update from 10.10.12.2 on FastEthernet1/0, 00:00:55 ago
  Routing Descriptor Blocks:
  * 10.10.12.2, from 10.10.0.2, 00:00:55 ago, via FastEthernet1/0
      Route metric is 2, traffic share count is 1


If TCP 3 Way Handshake process is successful before Connect Retry Timer expires, the BGP peer sends BGP OPEN message to its neighbor/peer and moves to Open Sent state. Else, the peer will move to Active state and again begins process of connectivity with the neighbor (waiting to complete 3-Way Handshake process).

Open sent: An open message was sent, with the parameters for the BGP session.

Open confirm: The router received agreement on the parameters for establishing a session. This happens when the BGP peer receives the OPEN message from the neighbor end also.  Else, the router goes into Active state if there is no response to the OPEN message.

After a BGP peer moves to Open Confirm state, it waits for the Keepalive message from its peer. Once the Keepalive message is received, the BGP peer moves to Established state and starts exchanging the prefixes using the Update Messages.

Established:  Neighborship is established between the peers and Update sharing begins. Below output shows BGP neighborship is UP between R1 and R2 from more than 5 mins.

R1#show ip bgp summary
BGP router identifier 10.10.0.1, local AS number 100
BGP table version is 3, main routing table version 3
2 network entries using 256 bytes of memory
2 path entries using 104 bytes of memory
2/2 BGP path/bestpath attribute entries using 248 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 608 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs

Neighbor        V           AS    MsgRcvd   MsgSent   TblVer  InQ  OutQ   Up/Down    State/PfxRcd
10.10.0.2        4           100     349             348             3          0        0      
05:15:23         1


R1#sh ip bgp neighbors
BGP neighbor is 10.10.0.2,  remote AS 100, internal link
  BGP version 4, remote router ID 10.10.0.2
  BGP state = Established, up for 05:15:23
  Last read 00:00:13, last write 00:00:27, hold time is 180, keepalive interval is 60 seconds

To summarize, as soon you enter the neighbor command, BGP starts in the IDLE state, and the BGP process checks that it has a route to the IP address listed. BGP should be in the IDLE state for only
a few seconds. If BGP does not find a route to the neighboring IP address, it stays in the
IDLE state. If it finds a route, it goes to the CONNECT state when the TCP handshaking synchronize acknowledge (SYN ACK) packet returns (when the TCP three-way handshake is complete).

After the TCP connection is set up, the BGP process creates a BGP Open message and sends it to the neighbor. After BGP dispatches this Open message, the BGP peering session changes to the OPEN SENT state. If there is no response for 5 seconds, the state changes to the ACTIVE state. If a response does come back in a timely manner, BGP goes to the OPEN CONFIRM state. Both peers exchange Keepalive messages as an acknowledgement of receipt of Open message and then move to ESTABLISHED State and starts scanning  the routing table for the paths to send to the neighbor via exchange Update messages.

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

EIGRP Tables

EIGRP maintains3 tables, Neighbor Table, Topology Table, and IP Routing table for its operation. This article will discuss these 3 tables in detail.


Let's discuss each of 3 tables in details using below topology.



Neighbor Table:

It is the first step of EIGRP operation to discover the neighbors. A router running EIGRP multicasts Hello  packets to discover the neighbors. An adjacency is created with these neighbors so that it can exchange route updates as a second step. Only the adjacent routers exchange routing information. Each router builds a neighbor table from the Hello packets it receives from adjacent EIGRP routers. To check the neighbor table, you can run "show ip eigrp neighbors" command.

R1#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(10)
H   Address                 Interface       Hold   Uptime   SRTT      RTO  Q    Seq
                                                       (sec)                   (ms)                Cnt  Num
2   10.10.13.3              PO2/0            10   00:01:05  369       2214   0      6
1   10.10.12.2              Fa1/0             12   00:01:07  256       1536   0     11
0   10.10.14.4              Se3/0             12   00:01:07  276       1656   0     15


  • H (handle): A number used internally by the Cisco IOS to track a neighbor. If there is a fourth router connected to R1, it would have an Handle number of 3.
  • Address: The neighbor’s IP address. It is the interface address of connected interface of neighbor.
  • Interface: The next hop interface on this router through which the neighbor can be reached.
  • Hold Time: The maximum time, in seconds, that the router waits to hear from the neighbor without receiving anything from a neighbor before considering the link unavailable.
  • Uptime: The elapsed time, in hours, minutes, and seconds since the local router first heard from this neighbor.
  • Smooth Round Trip Timer (SRTT): The average number (ms) it takes for an EIGRP packet to be sent to this neighbor and for the local router to receive an acknowledgment of that packet. This timer is used to determine the retransmit interval, also known as the retransmit timeout (RTO).
  • RTO—The amount of time, in milliseconds, that the router waits for an acknowledgment before retransmitting a reliable packet from the retransmission queue to a neighbor.
  • Queue count—The number of packets waiting in the queue to be sent out. If this value is constantly higher than 0, a congestion problem might exist. A  value of  '0' indicates that no EIGRP packets are in the queue. If the value of Q Count is non zero, there is delay, jitter on the link connected between neighbors and there will be slow convergence issues observed.
  • Seq Num—The sequence number of the last update, query, or reply packet that was received from this neighbor.

Topology Table:

Topology table is a kind of control plane or database of EIGRP where all routes learned from a neighbor are initially stored before the best routes are moved to the routing table.

We can use below commands to check details of the topology table.

  1. show ip eigrp topology
  2. show ip eigrp topology all-links
The first command only shows the details of successor as well as feasible successor links. We can see from the below output that for prefix 172.10.0.5/32, there is only next hop which is of successor (best path to reach 172.10.0.5/32). For the destination prefix 10.10.45.0/24, there are 2 best paths (equal-cost) and one FS.

R1#sh ip eigrp topology
EIGRP-IPv4 Topology Table for AS(10)/ID(172.10.0.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 172.10.0.5/32, 1 successors, FD is 149504
        via 10.10.13.3 (149504/146944), POS2/0

P 172.10.0.3/32, 1 successors, FD is 146944
        via 10.10.13.3 (146944/128256), POS2/0
P 10.10.13.0/24, 1 successors, FD is 18944
        via Connected, POS2/0
P 10.10.45.0/24, 2 successors, FD is 2174976
        via 10.10.12.2 (2174976/2172416), FastEthernet1/0
        via 10.10.13.3 (2174976/2172416), POS2/0
        via 10.10.14.4 (2681856/2169856), Serial3/0

----------------output omitted------------------

The second command slows all links irrespective of a path is a successor or a  feasible successor or not, as shown below:

R1#sh ip eigrp topology all-links
EIGRP-IPv4 Topology Table for AS(10)/ID(172.10.0.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 172.10.0.5/32, 1 successors, FD is 149504, serno 19
        via 10.10.13.3 (149504/146944), POS2/0
        via 10.10.12.2 (158720/156160), FastEthernet1/0
        via 10.10.14.4 (2809856/2297856), Serial3/0

P 172.10.0.3/32, 1 successors, FD is 146944, serno 17
        via 10.10.13.3 (146944/128256), POS2/0
P 10.10.13.0/24, 1 successors, FD is 18944, serno 4
        via Connected, POS2/0

P 10.10.45.0/24, 2 successors, FD is 2174976
        via 10.10.12.2 (2174976/2172416), FastEthernet1/0
        via 10.10.13.3 (2174976/2172416), POS2/0
        via 10.10.14.4 (2681856/2169856), Serial3/0

----------------output omitted------------------

Active (A) vs Passive (P) Route:

A route is considered to be in Passive state when the router is not performing any calculation or computation on that route. A route is considered to be in Active state  when it is undergoing re-computation (for example, when it is looking for a new successor). A Passive is the operational, stable state of the route.

If FS (feasible successor) for a prefix is always available, a destination prefix never has to go into the active state, thereby avoiding a recomputation. A prefix goes in Active state when the successor to a destination prefix, goes down and there are no FS available for the destination. The router initiates a re-computation by
sending a query packet to each of its neighboring routers. If the neighboring router has a route for the destination, it will send a reply packet; if it does not have a route, it sends a query packet to its neighbors.

Advertised Distance (AD): The AD is equal to the cost of the path to the destination prefix  as advertised by neighboring routers.For example, for the prefix 172.10.0.5/32 in the below output of topology table, the value 146944 is AD.

P 172.10.0.5/32, 1 successors, FD is 149504, serno 19
        via 10.10.13.3 (149504/146944), POS2/0

Feasible Distance (FD): It is equal to the sum of the AD for a neighbor to reach the destination prefix plus the metric to reach that neighbor. For example, for the prefix 172.10.0.5/32 in the below output of topology table, the value 149504 is FD.

P 172.10.0.5/32, 1 successors, FD is 149504, serno 19
        via 10.10.13.3 (149504/146944), POS2/0


Successor: The successor is the forwarding path (best route) used to reach the destination prefix. The cost of this path is equal to the FD. For example, for the destination prefix 10.10.45.0/24 from topology table, there are 2 successors (i.e. best equal cost paths to the destination). The prefix also has an FS via 10.10.14.4.
P 10.10.45.0/24, 2 successors, FD is 2174976
        via 10.10.12.2 (2174976/2172416), FastEthernet1/0
        via 10.10.13.3 (2174976/2172416), POS2/0
       
via 10.10.14.4 (2681856/2169856), Serial3/0

Feasible Successor: The FS is an alternative loop-free path to reach the destination Prefix. For example, in below output from topology table, the last path is FS.

P 10.10.45.0/24, 2 successors, FD is 2174976
       
via 10.10.12.2 (2174976/2172416), FastEthernet1/0
        via 10.10.13.3 (2174976/2172416), POS2/0
        via 10.10.14.4 (2681856/2169856), Serial3/0

Condition for a path to become an FS:

For a path to qualify as an FS, a next-hop router must have an AD less (strictly) than the FD of the current successor route for the particular network. Equal AD and FD values also doesn't meet the condition. For example, in below output for prefix 10.10.0.45/24 from topology table, last path is FS because it qualifies the condition. AD value 2169856 is less than FD of Successor paths (2174976).

P 10.10.45.0/24, 2 successors, FD is 2174976
       
via 10.10.12.2 (2174976/2172416), FastEthernet1/0
        via 10.10.13.3 (2174976/2172416), POS2/0
        via 10.10.14.4 (2681856/2169856), Serial3/0

For prefix 172.10.0.5/32, there is only one Successor, but not Feasible Successors because the last 2 paths doesn't qualify the condition to become FS.  The AD values 156160 and 2297856 are higher compared to FD 149504 of the Successor path.
P 172.10.0.5/32, 1 successors, FD is 149504, serno 19
        via 10.10.13.3 (149504/146944), POS2/0
        via 10.10.12.2 (158720/156160), FastEthernet1/0
        via 10.10.14.4 (2809856/2297856), Serial3/0

IP Routing Table:

The best paths of the topology table are moved to the routing table which can be checked using "show ip route"  or to specifically to check only EIGRP routes "show ip route eigrp" command.

R1#sh ip route eigrp
      10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
D        10.10.25.0/24 [90/30720] via 10.10.12.2, 02:46:30, FastEthernet1/0
D        10.10.35.0/24 [90/21504] via 10.10.13.3, 02:46:31, POS2/0
D        10.10.45.0/24 [90/2174976] via 10.10.13.3, 02:46:30, POS2/0
                       [90/2174976] via 10.10.12.2, 02:46:30, FastEthernet1/0
      172.10.0.0/32 is subnetted, 5 subnets
D        172.10.0.2 [90/156160] via 10.10.12.2, 02:46:32, FastEthernet1/0
D        172.10.0.3 [90/146944] via 10.10.13.3, 02:46:31, POS2/0
D        172.10.0.4 [90/2297856] via 10.10.14.4, 02:46:35, Serial3/0
       172.10.0.5 [90/149504] via 10.10.13.3, 02:46:30, POS2/0


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

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