RFC 7868
Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)
6.8. Classic Route Information TLV Types
6.8.1. Classic Flag Field Encoding
EIGRP transports a number of flags with in the TLVs to indicate addition route state information. These bits are defined as follows: Flags Field ----------- Source Withdraw (Bit 0) - Indicates if the router that is the original source of the destination is withdrawing the route from the network or if the destination is lost due as a result of a network failure. Candidate Default (CD) (Bit 1) - Set to indicate the destination should be regarded as a candidate for the default route. An EIGRP default route is selected from all the advertised candidate default routes with the smallest metric. ACTIVE (Bit 2) - Indicates if the route is in the ACTIVE State.6.8.2. Classic Metric Encoding
The handling of bandwidth and delay for Classic TLVs is encoded in the packet "scaled" form relative to how they are represented on the physical link. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scaled Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scaled Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reliability | Load | Internal Tag | Flags Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Scaled Delay: An administrative parameter assigned statically on a per-interface-type basis to represent the time it takes along an unloaded path. This is expressed in units of tens of microseconds divvied by 256. A delay of 0xFFFFFFFF indicates an unreachable route. Scaled Bandwidth: The path bandwidth measured in bits per second. In units of 2,560,000,000/kbps.
MTU: The minimum MTU size for the path to the destination.
Hop Count: The number of router traversals to the destination.
Reliability: The current error rate for the path, measured as an
error percentage. A value of 255 indicates 100% reliability
Load: The load utilization of the path to the destination, measured
as a percentage. A value of 255 indicates 100% load.
Internal-Tag: A tag assigned by the network administrator that is
untouched by EIGRP. This allows a network administrator to filter
routes in other EIGRP border routers based on this value.
Flags Field: See Section 6.8.1.
6.8.3. Classic Exterior Encoding
Additional routing information so provided for destinations outside
of the EIGRP AS as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Identifier (RID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Autonomous System (AS) Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Protocol Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Extern Protocol| Flags Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router Identifier (RID): A 32-bit number provided by the router
sourcing the information to uniquely identify it as the source.
External Autonomous System (AS) Number: A 32-bit number indicating
the external AS of which the sending router is a member. If the
source protocol is EIGRP, this field will be the [VRID, AS] pair.
If the external protocol does not have an AS, other information
can be used (for example, Cisco uses process-id for OSPF).
Administrative Tag: A tag assigned by the network administrator that
is untouched by EIGRP. This allows a network administrator to
filter routes in other EIGRP border routers based on this value.
External Protocol Metric: 32-bit value of the composite metric that
resides in the routing table as learned by the foreign protocol.
If the External Protocol is IGRP or another EIGRP routing process,
the value can optionally be the composite metric or 0, and the
metric information is stored in the metric section.
External Protocol: Contains an enumerated value defined in Section
6.2 to identify the routing protocol (external protocol)
redistributing the route.
Flags Field: See Section 6.8.1
6.8.4. Classic Destination Encoding
EIGRP carries destination in a compressed form, where the number of
bits significant in the variable-length address field are indicated
in a counter.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subnet Mask | Destination Address (variable length) |
| Bit Count | ((Bit Count - 1) / 8) + 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subnet Mask Bit Count: 8-bit value used to indicate the number of
bits in the subnet mask. A value of 0 indicates the default
network, and no address is present.
Destination Address: A variable-length field used to carry the
destination address. The length is determined by the number of
consecutive bits in the destination address. The formula to
calculate the length is address-family dependent:
IPv4: ((Bit Count - 1) / 8) + 1
IPv6: (Bit Count == 128) ? 16 : ((x / 8) + 1)
6.8.5. IPv4-Specific TLVs
INTERNAL_TYPE 0x0102
EXTERNAL_TYPE 0x0103
COMMUNITY_TYPE 0x0104
6.8.5.1. IPv4 INTERNAL_TYPE
This TLV conveys IPv4 destination and associated metric information for IPv4 networks. Routes advertised in this TLV are network interfaces that EIGRP is configured on as well as networks that are learned via other routers running EIGRP. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 | 0x02 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next-Hop Forwarding Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vector Metric Section (see Section 6.8.2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Destination Section | | IPv4 Address (variable length) | | (see Section 6.8.4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next-Hop Forwarding Address: IPv4 address represented by four 8-bit values (total 4 octets). If the value is zero (0), the IPv4 address from the received IPv4 header is used as the next hop for the route. Otherwise, the specified IPv4 address will be used. Vector Metric Section: The vector metrics for destinations contained in this TLV. See the description of "metric encoding" in Section 6.8.2. Destination Section: The network/subnet/host destination address being requested. See the description of "destination" in Section 6.8.4.6.8.5.2. IPv4 EXTERNAL_TYPE
This TLV conveys IPv4 destination and metric information for routes learned by other routing protocols that EIGRP injects into the AS. Available with this information is the identity of the routing protocol that created the route, the external metric, the AS number, an indicator if it should be marked as part of the EIGRP AS, and a network-administrator tag used for route filtering at EIGRP AS boundaries.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 | 0x03 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next-Hop Forwarding Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exterior Section (see Section 6.8.3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vector Metric Section (see Section 6.8.2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Destination Section | | IPv4 Address (variable length) | | (see Section 6.8.4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next-Hop Forwarding Address: IPv4 address represented by four 8-bit values (total 4 octets). If the value is zero (0), the IPv4 address from the received IPv4 header is used as the next hop for the route. Otherwise, the specified IPv4 address will be used. Exterior Section: Additional routing information provided for a destination that is outside of the AS and that has been redistributed into the EIGRP. See the description of "exterior encoding" in Section 6.8.3. Vector Metric Section: Vector metrics for destinations contained in this TLV. See the description of "metric encoding" in Section 6.8.2. Destination Section: The network/subnet/host destination address being requested. See the description of "destination" in Section 6.8.4.
6.8.5.3. IPv4 COMMUNITY_TYPE
This TLV is used to provide community tags for specific IPv4 destinations. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 | 0x04 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Community Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Community List | | (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Destination: The IPv4 address with which the community information should be stored. Community Length: A 2-octet unsigned number that indicates the length of the Community List. The length does not include the IPv4 Address, Reserved, or Length fields. Community List: One or more 8-octet EIGRP communities, as defined in Section 6.4.6.8.6. IPv6-Specific TLVs
INTERNAL_TYPE 0x0402 EXTERNAL_TYPE 0x0403 COMMUNITY_TYPE 0x0404
6.8.6.1. IPv6 INTERNAL_TYPE
This TLV conveys the IPv6 destination and associated metric information for IPv6 networks. Routes advertised in this TLV are network interfaces that EIGRP is configured on as well as networks that are learned via other routers running EIGRP. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x04 | 0x02 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Next-Hop Forwarding Address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vector Metric Section (see Section 6.8.2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Destination Section | | IPv6 Address (variable length) | | (see Section 6.8.4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next-Hop Forwarding Address: This IPv6 address is represented by eight groups of 16-bit values (total 16 octets). If the value is zero (0), the IPv6 address from the received IPv6 header is used as the next hop for the route. Otherwise, the specified IPv6 address will be used. Vector Metric Section: Vector metrics for destinations contained in this TLV. See the description of "metric encoding" in Section 6.8.2. Destination Section: The network/subnet/host destination address being requested. See the description of "destination" in Section 6.8.4.6.8.6.2. IPv6 EXTERNAL_TYPE
This TLV conveys IPv6 destination and metric information for routes learned by other routing protocols that EIGRP injects into the topology. Available with this information is the identity of the routing protocol that created the route, the external metric, the AS number, an indicator if it should be marked as part of the EIGRP AS, and a network administrator tag used for route filtering at EIGRP AS boundaries.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x04 | 0x03 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Next-Hop Forwarding Address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Exterior Section (see Section 6.8.3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vector Metric Section (see Section 6.8.2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Destination Section | | IPv6 Address (variable length) | | (see Section 6.8.4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next-Hop Forwarding Address: IPv6 address is represented by eight groups of 16-bit values (total 16 octets). If the value is zero (0), the IPv6 address from the received IPv6 header is used as the next hop for the route. Otherwise, the specified IPv6 address will be used. Exterior Section: Additional routing information provided for a destination that is outside of the AS and that has been redistributed into the EIGRP. See the description of "exterior encoding" in Section 6.8.3. Vector Metric Section: vector metrics for destinations contained in this TLV. See the description of "metric encoding" in Section 6.8.2. Destination Section: The network/subnet/host destination address being requested. See the description of "destination" in Section 6.8.4.
6.8.6.3 IPv6 COMMUNITY_TYPE
This TLV is used to provide community tags for specific IPv4 destinations. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x04 | 0x04 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Community Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Community List | | (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Destination: The IPv6 address with which the community information should be stored. Community Length: A 2-octet unsigned number that indicates the length of the Community List. The length does not include the IPv6 Address, Reserved, or Length fields. Community List: One or more 8-octet EIGRP communities, as defined in Section 6.4.
6.9. Multiprotocol Route Information TLV Types
This TLV conveys topology and associated metric information. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Header Version | Opcode | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Virtual Router ID | Autonomous System Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Header Encoding | | (see Section 6.9.1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wide Metric Encoding | | (see Section 6.9.2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Descriptor | | (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+6.9.1. TLV Header Encoding
There has been a long-standing requirement for EIGRP to support routing technologies, such as multi-topologies, and to provide the ability to carry destination information independent of the transport. To accomplish this, a Vector has been extended to have a new "Header Extension Header" section. This is a variable-length field and, at a minimum, it will support the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type High | Type Low | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFI | TID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Identifier (RID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The available fields are:
TYPE - Topology TLVs have the following TYPE codes:
Type High: 0x06
Type Low:
REQUEST_TYPE 0x01
INTERNAL_TYPE 0x02
EXTERNAL_TYPE 0x03
Router Identifier (RID): A 32-bit number provided by the router
sourcing the information to uniquely identify it as the source.
6.9.2. Wide Metric Encoding
Multiprotocol TLVs will provide an extendable section of metric
information, which is not used for the primary routing compilation.
Additional per-path information is included to enable per-path cost
calculations in the future. Use of the per-path costing along with
the VID/TID will prove a complete solution for multidimensional
routing.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Priority | Reliability | Load |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Opaque Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Attributes |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows:
Offset: Number of 16-bit words in the Extended Attribute section that
are used to determine the start of the destination information. A
value of zero indicates no Extended Attributes are attached.
Priority: Priority of the prefix when processing a route. In an AS
using priority values, a destination with a higher priority
receives preferential treatment and is serviced before a
destination with a lower priority. A value of zero indicates no
priority is set.
Reliability: The current error rate for the path. Measured as an
error percentage. A value of 255 indicates 100% reliability
Load: The load utilization of the path to the destination, measured
as a percentage. A value of 255 indicates 100% load.
MTU: The minimum MTU size for the path to the destination. Not used
in metric calculation but available to underlying protocols
Hop Count: The number of router traversals to the destination.
Delay: The one-way latency along an unloaded path to the destination
expressed in units of picoseconds per kilobit. This number is not
scaled; a value of 0xFFFFFFFFFFFF indicates an unreachable route.
Bandwidth: The path bandwidth measured in kilobit per second as
presented by the interface. This number is not scaled; a value of
0xFFFFFFFFFFFF indicates an unreachable route.
Reserved: Transmitted as 0x0000.
Opaque Flags: 16-bit protocol-specific flags. Values currently
defined by Cisco are:
OPAQUE_SRCWD 0x01 Route Source Withdraw
OPAQUE_CD 0x02 Candidate default route
OPAQUE_ACTIVE 0x04 Route is currently in active state
OPAQUE_REPL 0x08 Route is replicated from another VRF
Extended Attributes (Optional): When present, defines extendable per-
destination attributes. This field is not normally transmitted.
6.9.3. Extended Metrics
Extended metrics allow for extensibility of the vector metrics in a
manner similar to RFC 6390 [11]. Each Extended metric shall consist
of a header identifying the type (Opcode) and the length (Offset)
followed by application-specific information. Extended metric values
not understood must be treated as opaque and passed along with the
associated route.
The general formats for the Extended Metric fields are: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Opcode | Offset | Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Opcode: Indicates the type of Extended Metric. Offset: Number of 16-bit words in the application-specific information. Offset does not include the length of the Opcode or Offset. Data: Zero or more octets of data as defined by Opcode.6.9.3.1. 0x00 - NoOp
This is used to pad the attribute section to ensure 32-bit alignment of the metric encoding section. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 | 0x00 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The fields are: Opcode: Transmitted as zero (0). Offset: Transmitted as zero (0) indicating no data is present. Data: No data is present with this attribute.
6.9.3.2. 0x01 - Scaled Metric
If a route is received from a back-rev neighbor, and the route is selected as the best path, the scaled metric received in the older UPDATE may be attached to the packet. If received, the value is for informational purposes and is not affected by K6. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x01 | 0x04 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scaled Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scaled Delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: Transmitted as 0x0000 Scaled Bandwidth: The minimum bandwidth along a path expressed in units of 2,560,000,000/kbps. A bandwidth of 0xFFFFFFFF indicates an unreachable route. Scaled Delay: An administrative parameter assigned statically on a per-interface-type basis to represent the time it takes along an unloaded path. This is expressed in units of tens of microseconds divvied by 256. A delay of 0xFFFFFFFF indicates an unreachable route.6.9.3.3. 0x02 - Administrator Tag
EIGRP administrative tag does not alter the path decision-making process. Routers can set a tag value on a route and use the flags to apply specific routing polices within their network. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x02 | 0x02 | Administrator Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Administrator Tag (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Administrator Tag: A tag assigned by the network administrator that is untouched by EIGRP. This allows a network administrator to filter routes in other EIGRP border routers based on this value.
6.9.3.4. 0x03 - Community List
EIGRP communities themselves do not alter the path decision-making process, communities can be used as flags in order to mark a set of routes. Upstream routers can then use these flags to apply specific routing polices within their network. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x03 | Offset | Community List | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Offset: Number of 16-bit words in the sub-field. Community List: One or more 8-octet EIGRP communities, as defined in Section 6.4.6.9.3.5. 0x04 - Jitter
(Optional) EIGRP can carry one-way Jitter in networks that carry UDP traffic if the node is capable of measuring UDP Jitter. The Jitter reported to will be averaged with any existing Jitter data and include in the route updates. If no Jitter value is reported by the peer for a given destination, EIGRP will use the locally collected value. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x04 | 0x03 | Jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jitter: The measure of the variability over time of the latency across a network measured in measured in microseconds.6.9.3.6. 0x05 - Quiescent Energy
(Optional) EIGRP can carry energy usage by nodes in networks if the node is capable of measuring energy. The Quiescent Energy reported will be added to any existing energy data and include in the route updates. If no energy data is reported by the peer for a given destination, EIGRP will use the locally collected value.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x05 | 0x02 | Q-Energy (high) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Q-Energy (low) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Q-Energy: Paths with higher idle (standby) energy usage will be reflected in a higher aggregate metric than those having lower energy usage. If present, this number will represent the idle power consumption expressed in milliwatts per kilobit.6.9.3.7. 0x06 - Energy
(Optional) EIGRP can carry energy usage by nodes in networks if the node is capable of measuring energy. The active Energy reported will be added to any existing energy data and include in the route updates. If no energy data is reported by the peer for a given destination, EIGRP will use the locally collected value. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x06 | 0x02 | Energy (high) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Energy (low) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Energy: Paths with higher active energy usage will be reflected in a higher aggregate metric than those having lower energy usage. If present, this number will represent the power consumption expressed in milliwatts per kilobit.6.9.3.8. 0x07 - AddPath
The Add Path enables EIGRP to advertise multiple best paths to adjacencies. There will be up to a maximum of four AddPaths supported, where the format of the field will be as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x07 | Offset | AddPath (Variable Length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Offset: Number of 16-bit words in the sub-field.
AddPath: Length of this field will vary in length based on whether it
contains IPv4 or IPv6 data.
6.9.3.8.1. AddPath with IPv4 Next Hop
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x07 | Offset | Next-Hop Addr. (Upper 2 bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (Lower 2 bytes) | RID (Upper 2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RID (Upper 2 bytes) | Admin Tag (Upper 2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Admin Tag (Upper 2 bytes) |Extern Protocol| Flags Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next-Hop Address: An IPv4 address represented by four 8-bit values
(total 4 octets). If the value is zero (0), the IPv6 address from
the received IPv4 header is used as the next hop for the route.
Otherwise, the specified IPv4 address will be used.
Router Identifier (RID): A 32-bit number provided by the router
sourcing the information to uniquely identify it as the source.
Admin Tag: A 32-bit administrative tag assigned by the network. This
allows a network administrator to filter routes based on this
value.
If the route is of type external, then two additional bytes will be
added as follows:
External Protocol: Contains an enumerated value defined in Section
6.2 to identify the routing protocol (external protocol)
redistributing the route.
Flags Field: See Section 6.8.1.
6.9.3.8.2. AddPath with IPv6 Next Hop
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x07 | Offset | Next-Hop Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | (16 octets) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | RID (Upper 2 byes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RID (Upper 2 byes) | Admin Tag (Upper 2 byes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Admin Tag (Upper 2 byes) | Extern Protocol | Flags Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next-Hop Address: An IPv6 address represented by eight groups of 16-bit values (total 16 octets). If the value is zero (0), the IPv6 address from the received IPv6 header is used as the next hop for the route. Otherwise, the specified IPv6 address will be used. Router Identifier (RID): A 32-bit number provided by the router sourcing the information to uniquely identify it as the source. Admin Tag: A 32-bit administrative tag assigned by the network. This allows a network administrator to filter routes based on this value. If the route is of type external, then two addition bytes will be added as follows: External Protocol: Contains an enumerated value defined in Section 6.2 to identify the routing protocol (external protocol) redistributing the route. Flags Field: See Section 6.8.1.
6.9.4. Exterior Encoding
Additional routing information provided for destinations outside of the EIGRP AS as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Identifier (RID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Autonomous System (AS) Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Protocol Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Extern Protocol| Flags Field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Router Identifier (RID): A 32-bit number provided by the router sourcing the information to uniquely identify it as the source. External Autonomous System (AS) Number: A 32-bit number indicating the external AS of which the sending router is a member. If the source protocol is EIGRP, this field will be the [VRID, AS] pair. If the external protocol does not have an AS, other information can be used (for example, Cisco uses process-id for OSPF). External Protocol Metric: A 32-bit value of the metric used by the routing table as learned by the foreign protocol. If the External Protocol is IGRP or EIGRP, the value can (optionally) be 0, and the metric information is stored in the metric section. External Protocol: Contains an enumerated value defined in Section 6.2 to identify the routing protocol (external protocol) redistributing the route. Flags Field: See Section 6.8.1.
6.9.5. Destination Encoding
Destination information is encoded in Multiprotocol packets in the same manner used by Classic TLVs. This is accomplished by using a counter to indicate how many significant bits are present in the variable-length address field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subnet Mask | Destination Address (variable length | | Bit Count | ((Bit Count - 1) / 8) + 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subnet Mask Bit Count: 8-bit value used to indicate the number of bits in the subnet mask. A value of 0 indicates the default network and no address is present. Destination Address: A variable-length field used to carry the destination address. The length is determined by the number of consecutive bits in the destination address. The formula to calculate the length is address-family dependent: IPv4: ((Bit Count - 1) / 8) + 1 IPv6: (Bit Count == 128) ? 16 : ((x / 8) + 1)6.9.6. Route Information
6.9.6.1. INTERNAL TYPE
This TLV conveys destination information based on the IANA AFI defined in the TLV Header (see Section 6.9.1), and associated metric information. Routes advertised in this TLV are network interfaces that EIGRP is configured on as well as networks that are learned via other routers running EIGRP.6.9.6.2. EXTERNAL TYPE
This TLV conveys destination information based on the IANA AFI defined in the TLV Header (see Section 6.9.1), and metric information for routes learned by other routing protocols that EIGRP injects into the AS. Available with this information is the identity of the routing protocol that created the route, the external metric, the AS number, an indicator if it should be marked as part of the EIGRP AS, and a network administrator tag used for route filtering at EIGRP AS boundaries.
7. Security Considerations
Being promiscuous, EIGRP will neighbor with any router that sends a valid HELLO packet. Due to security considerations, this "completely" open aspect requires policy capabilities to limit peering to valid routers. EIGRP does not rely on a PKI or a heavyweight authentication system. These systems challenge the scalability of EIGRP, which was a primary design goal. Instead, Denial-of-Service (DoS) attack prevention will depend on implementations rate-limiting packets to the control plane as well as authentication of the neighbor through the use of MD5 or SHA2-256 [6].8. IANA Considerations
This document serves as the sole reference for two multicast addresses: 224.0.0.10 for IPv4 "EIGRP Routers" [13] and FF02:0:0:0:0:0:0:A for IPv6 "EIGRP Routers" [14]. It also serves as assignment for protocol number 88 (EIGRP) [15].9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [2] Garcia-Luna-Aceves, J.J., "A Unified Approach to Loop-Free Routing Using Distance Vectors or Link States", SIGCOMM '89, Symposium proceedings on Communications architectures & protocols, Volume 19, pages 212-223, ACM 089791-332-9/89/0009/0212, DOI 10.1145/75247.75268, 1989. [3] Garcia-Luna-Aceves, J.J., "Loop-Free Routing using Diffusing Computations", Network Information Systems Center, SRI International, appeared in IEEE/ACM Transactions on Networking, Vol. 1, No. 1, DOI 10.1109/90.222913, 1993. [4] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, <http://www.rfc-editor.org/info/rfc7153>.
[5] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, <http://www.rfc-editor.org/info/rfc3692>. [6] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <http://www.rfc-editor.org/info/rfc4868>. [7] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <http://www.rfc-editor.org/info/rfc1112>. [8] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>. [9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.9.2. Informative References
[10] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>. [11] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <http://www.rfc-editor.org/info/rfc6390>. [12] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>. [13] IANA, "IPv4 Multicast Address Space Registry", <http://www.iana.org/assignments/multicast-addresses>. [14] IANA, "IPv6 Multicast Address Space Registry", <http://www.iana.org/assignments/ipv6-multicast-addresses>. [15] IANA, "Protocol Numbers", <http://www.iana.org/assignments/protocol-numbers>.
Acknowledgments
Thank you goes to Dino Farinacci, Bob Albrightson, and Dave Katz. Their significant accomplishments towards the design and development of the EIGRP provided the bases for this document. A special and appreciative thank you goes to the core group of Cisco engineers whose dedication, long hours, and hard work led the evolution of EIGRP over the past decade. They are Donnie Savage, Mickel Ravizza, Heidi Ou, Dawn Li, Thuan Tran, Catherine Tran, Don Slice, Claude Cartee, Donald Sharp, Steven Moore, Richard Wellum, Ray Romney, Jim Mollmann, Dennis Wind, Chris Van Heuveln, Gerald Redwine, Glen Matthews, Michael Wiebe, and others. The authors would like to gratefully acknowledge many people who have contributed to the discussions that lead to the making of this proposal. They include Chris Le, Saul Adler, Scott Van de Houten, Lalit Kumar, Yi Yang, Kumar Reddy, David Lapier, Scott Kirby, David Prall, Jason Frazier, Eric Voit, Dana Blair, Jim Guichard, and Alvaro Retana. In addition to the tireless work provided by the Cisco engineers over the years, we would like to personally recognize the teams that created open source versions of EIGRP: o Linux implementation developed by the Quagga team: Jan Janovic, Matej Perina, Peter Orsag, and Peter Paluch. o BSD implementation developed and released by Renato Westphal.
Authors' Addresses
Donnie V. Savage Cisco Systems, Inc. 7025 Kit Creek Rd., RTP, Morrisville, NC 27560 United States Phone: 919-392-2379 Email: dsavage@cisco.com James Ng Cisco Systems, Inc. 7025 Kit Creek Rd., RTP, Morrisville, NC 27560 United States Phone: 919-392-2582 Email: jamng@cisco.com Steven Moore Cisco Systems, Inc. 7025 Kit Creek Rd., RTP, Morrisville, NC 27560 United States Phone: 408-895-2031 Email: smoore@cisco.com Donald Slice Cumulus Networks Apex, NC United States Email: dslice@cumulusnetworks.com Peter Paluch University of Zilina Univerzitna 8215/1, Zilina 01026 Slovakia Phone: 421-905-164432 Email: Peter.Paluch@fri.uniza.sk Russ White LinkedIn Apex, NC United States Phone: 1-877-308-0993 Email: russw@riw.us