EIGRP – Various Packet Types

 EIGRP, Networking  Comments Off on EIGRP – Various Packet Types
Dec 132022
 

In this third post in our EIGRP series, let’s consider the various packet types used and their purpose.

Altogether, we encounter five packet types in EIGRP that are used to establish adjacencies and share routing information.

The packet types include: Hello, Acknowledgment, Update, Query and Reply.

Some of the EIGRP packet types are reliable and require an acknowledgment while others are unreliable and do not need an acknowledgment.

The OPCode field in the EIGRP packet header identifies the packet type:

OPCode 1: Update packet
OPCode 3: Query packet
OPCode 4: Reply packet
OPCode 5: Hello and ACK packets

EIGRP Hello Packet

EIGRP Packet Types:

It’s time to consider each of the EIGRP packet types and their purpose.

* Hello:
# Discover and form adacencies with Neighbors (Other EIGRP routers in the NW)
# Hello packets are sent unreliably and do NOT require acknowledgements
# Continued receipt of Hellos maintains Neighbor Table
# Hello packets are sent via multicast

* Acknowledgment:
# Acknowledgements packets are “dataless” Hello packets with just a sequence number
# They indicate receipt of any EIGRP packet during a “reliable” (Reliable Transport Protocol) exchange
# Will acknowledge receipt of Update, Query and Reply packets

* Update:
# Transmit Routability and Reachability information with other EIGRP Neighbors
# Carry prefix and metric information
# Sent to initially exchange topology information or topology change
# Later Updates sent ONLY when necessary, such as when a new destination prefix becomes reachable or the cost of an already reachable destination prefix changes
# So updates are non-periodic, i.e., not sent at scheduled intervals
# EIGRP updates contain only needed routing information and are unicast to routers that require it
# Update packets can also be multicast (like when a link cost changes)
# Sent reliably and require acknowledgments

* Query:
# Query packets are sent when destinations go into Active state
# Used to get specific information from one or more Neighbors; Sent to search for another path during convergence
# Query packets are multicast to all peers on all interfaces except for the interface to the previous Successor
# Sent reliably and require acknowledgements

* Reply:
# Reply packets are unicast to the originator of the query
# Sent reliably and require acknowledgements

Reliable Packets:

Reliable packets require explicit acknowledgement from destination.

They are sequenced and retransmitted up to 16 times if not acknowledged.
Reliable packets are:
• Updates
• Queries
• Replies
• SIA-Queries
• SIA-Replies

Unreliable packets do not require acknowledgement from destination:
# Hello and ACK

How to Verify EIGRP Packets

A few days back, we did a basic EIGRP configuration.

As part of that basic EIGRP lab, we ran a bunch of commands including one that let us view the various EIGRP packets on a Router.

EIGRP Configuration on Packet Tracer

Take a look below at various EIGRP Packets on the three Routers R1, R2 and R3:

R1#sh ip eigrp traffic
IP-EIGRP Traffic Statistics for process 1
Hellos sent/received: 1211/1170
Updates sent/received: 8/6
Queries sent/received: 0/0
Replies sent/received: 0/0
Acks sent/received: 5/8
Input queue high water mark 1, 0 drops
SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0
R2#sh ip eigrp traffic
IP-EIGRP Traffic Statistics for process 1
Hellos sent/received: 1167/1162
Updates sent/received: 6/10
Queries sent/received: 0/0
Replies sent/received: 0/0
Acks sent/received: 10/6
Input queue high water mark 1, 0 drops
SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0
R3#sh ip eigrp traffic
IP-EIGRP Traffic Statistics for process 1
Hellos sent/received: 1140/1137
Updates sent/received: 7/5
Queries sent/received: 0/0
Replies sent/received: 0/0
Acks sent/received: 5/6
Input queue high water mark 1, 0 drops
SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0

EIGRP Routing Protocol – Primer

 EIGRP  Comments Off on EIGRP Routing Protocol – Primer
Dec 132022
 

In our last post, we took a look at a basic EIGRP configuration.

Now we’ll take a step back and consider some of the essential features of EIGRP.

EIGRP is a Cisco-proprietary dynamic routing protocol that debuted in 1992.

Although Cisco attempted to make it an open standard protocol a few years later, for all intents and purposes EIGRP is still largely used on Cisco routers.

In upcoming posts, we’ll consider more EIGRP features including Classic and Named modes, Authentication, Packet Types, Metric calculation, and Route Redistribution.

EIGRP Configuration on Packet Tracer

EIGRP: Essential Features

* Cisco-proprietary routing protocol (1992)
* Classless, advanced Distance Vector Routing Protocol
* In EIGRP, the topology information beyond the next hop is hidden (just like with the seldom-used RIP distance vector protocol)
* EIGRP only knows prefix and next-hop information
* EIGRP Administrative Distance (AD) is 90. Lower the AD, the more believable the Route is
* EIGRP uses the concept of Autonomous System to exchange routes
* An Autonomous System is nothing more than a collection of networks under the control of a single authority (RFC 1930)
* EIGRP Metric Calculation Relies on four components: Bandwidth, Delay, Reliability, Load, MTU
* By default, we consider only Bandwidth and Delay in calculating the EIGRP Metric
* Go with lowest Feasible Distance (more on that later)
* EIGRP Convergence technology is based on the Diffusing Update Algorithm (DUAL)
* Purpose of DUAL is to guarantee loop-free and backup paths throughout the EIGRP routing domain
* Partial triggered updates when a path or metric changes
* Provides both Equal & Unequal Cost Load Balancing
* EIGRP neighbors communicate via IP Protocol 88 by sending Hello Packets to Multicast address 224.0.0.10
* EIGRP uses concepts of Internal Routes (Originates from within an EIGRP Autonomous System) & External Routes (Redistributed from outside of EIGRP Autonomous System)
* Internal EIGRP Routes have AD of 90
* External EIGRP routes have AD of 170
* EIGRP relies on the key concepts of Hello Interval & Hold Time
* EIGRP Hello Interval – How long a local Router waits between sending Hello messages to a neighbor; Default Hello Interval on Broadcast NW: 5-seconds
* EIGRP Hold Time – Tells an EIGRP neighbor how long to wait before considering local router unavailable; Default Hold Time on Broadcast NW: 15-seconds
* EIGRP load balances across unequal cost links using the variance feature
* Supports Authentication with other EIGRP Routers
* Uses Reliable Transport Protocol (RTP) to deliver EIGRP Packets
* Update, Query & Reply packets require Acknowledgment; Hello & Acknowledgment packets do not require Acknowledgment
* EIGRP Does NOT work well in mixed environments

How to Configure Basic EIGRP

 EIGRP  Comments Off on How to Configure Basic EIGRP
Dec 012022
 

EIGRP Configuration on Packet Tracer

In this lab, we’ll do a basic configuration of EIGRP and then run a bunch of verify commands.

We’ll finish off with a ping test to verify end-to-end connectivity between the PCs.

This time the lab is being done on Packet Tracer instead of GNS3. Packet Tracer is easier to set up compared to GNS3 and available as a free download from Cisco.

Another plus with Packet Tracer is that it also runs on different operating systems including Windows, Mac and Linux.

This EIGRP lab is part of Cisco Netacad CCNA curriculum.

The various interfaces on Routers have already been configured and we’ll verify them with the show ip interface brief command.

Passive Interfaces

We’ll also configure passive-interfaces on the three LAN segments attached to R1, R2 and R3.

The point of configuring passive-interfaces is to prevent the LAN interfaces from advertising EIGRP updates.

As part of our EIGRP configuration, we’ll disable auto-summarization and also make the LAN interfaces passive.

Verify Interfaces on Routers

Let’s first take a quick look at the IP addressing on the three routers:

R1#show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 172.16.1.1 YES manual up up
GigabitEthernet0/1 unassigned YES unset administratively down down
Serial0/0/0 172.16.3.1 YES manual up up
Serial0/0/1 192.168.10.5 YES manual up up
Vlan1 unassigned YES unset administratively down down
R2#show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 172.16.2.1 YES manual up up
GigabitEthernet0/1 unassigned YES unset administratively down down
Serial0/0/0 172.16.3.2 YES manual up up
Serial0/0/1 192.168.10.9 YES manual up up
Serial0/1/0 unassigned YES unset down down
Serial0/1/1 unassigned YES unset administratively down down
Vlan1
R3#show ip interface brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 192.168.1.1 YES manual up up
GigabitEthernet0/1 unassigned YES unset administratively down down
Serial0/0/0 192.168.10.6 YES manual up up
Serial0/0/1 192.168.10.10 YES manual up up
Vlan1 unassigned YES unset administratively down down

The IP addressing looks good on the three routers.

Configure EIGRP Protocol

Now that we’ve verified the interfaces, let’s start configuring EIGRP on the three routers (R1, R2 and R3).

As you can see below, the EIGRP configuration process is simple.

R1(config)# router eigrp 1
network 172.16.1.0 0.0.0.255
network 172.16.3.0 0.0.0.3
network 192.168.10.4 0.0.0.3
no auto-summary
passive-interface g0/0
end
R2(config)# router eigrp 1
network 172.16.2.0 0.0.0.255
network 172.16.3.0 0.0.0.255
network 192.168.10.8 0.0.0.3
no auto-summary
passive-interface g0/0
end
R3(config)# router eigrp 1
network 192.168.10.4 0.0.0.3
network 192.168.10.8 0.0.0.3
network 192.168.1.0 0.0.0.255
no auto-summary
passive-interface g0/0
end
Verify EIGRP Commands

There are a whole bunch of verify commands when it comes to EIGRP.

We’ll run the key ones below.

Let’s start by looking at the Routing Table on R1:

R1#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/16 is variably subnetted, 5 subnets, 3 masks
C       172.16.1.0/24 is directly connected, GigabitEthernet0/0
L       172.16.1.1/32 is directly connected, GigabitEthernet0/0
D       172.16.2.0/24 [90/2170112] via 172.16.3.2, 00:08:06, Serial0/0/0
C       172.16.3.0/30 is directly connected, Serial0/0/0
L       172.16.3.1/32 is directly connected, Serial0/0/0
D    192.168.1.0/24 [90/2170112] via 192.168.10.6, 00:07:38, Serial0/0/1
     192.168.10.0/24 is variably subnetted, 3 subnets, 2 masks
C       192.168.10.4/30 is directly connected, Serial0/0/1
L       192.168.10.5/32 is directly connected, Serial0/0/1
D       192.168.10.8/30 [90/2681856] via 172.16.3.2, 00:08:06, Serial0/0/0
                        [90/2681856] via 192.168.10.6, 00:07:38, Serial0/0/1

The D in the Routing Table indicates the destination network is reachable via EIGRP.

The Administrative Distance (90) and Metric are also shown in the Routing Table. To reach the 172.16.2.0 network, the metric is 2170112.

When you append eigrp to show ip route, you’ll see just the EIGRP routes (see below).

R1#sh ip route eigrp
     172.16.0.0/16 is variably subnetted, 5 subnets, 3 masks
D       172.16.2.0/24 [90/2170112] via 172.16.3.2, 00:11:03, Serial0/0/0
D    192.168.1.0/24 [90/2170112] via 192.168.10.6, 00:10:35, Serial0/0/1
     192.168.10.0/24 is variably subnetted, 3 subnets, 2 masks
D       192.168.10.8/30 [90/2681856] via 172.16.3.2, 00:11:03, Serial0/0/0
                        [90/2681856] via 192.168.10.6, 00:10:35, Serial0/0/1</pre
Verifying EIGRP Neighbors on R1:
R1#sh ip eigrp neighbors
IP-EIGRP neighbors for process 1
H   Address         Interface      Hold Uptime    SRTT   RTO   Q   Seq
                                   (sec)          (ms)        Cnt  Num
0   172.16.3.2      Se0/0/0        12   00:12:47  40     1000  0   7
1   192.168.10.6    Se0/0/1        12   00:12:19  40     1000  0   10

Not all routes in the Topology Table get installed into the EIGRP routing table.

Only the “Best Routes” in the EIGRP Topology Table make it to the Routing Table.

Here’s the topology table for R1:

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS 1/ID(192.168.10.5)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - Reply status

P 172.16.1.0/24, 1 successors, FD is 2816
         via Connected, GigabitEthernet0/0
P 172.16.2.0/24, 1 successors, FD is 2170112
         via 172.16.3.2 (2170112/2816), Serial0/0/0
P 172.16.3.0/30, 1 successors, FD is 2169856
         via Connected, Serial0/0/0
P 192.168.1.0/24, 1 successors, FD is 2170112
         via 192.168.10.6 (2170112/2816), Serial0/0/1
P 192.168.10.4/30, 1 successors, FD is 2169856
         via Connected, Serial0/0/1
P 192.168.10.8/30, 2 successors, FD is 2681856
         via 172.16.3.2 (2681856/2169856), Serial0/0/0
         via 192.168.10.6 (2681856/2169856), Serial0/0/1

One of my favorite EIGRP verify commands is show ip protocols.

This command spits out a wealth of information (see below).

R1#sh ip protocols

Routing Protocol is "eigrp  1 " 
  Outgoing update filter list for all interfaces is not set 
  Incoming update filter list for all interfaces is not set 
  Default networks flagged in outgoing updates  
  Default networks accepted from incoming updates 
  Redistributing: eigrp 1
  EIGRP-IPv4 Protocol for AS(1)
    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
    NSF-aware route hold timer is 240
    Router-ID: 172.16.1.1
    Topology : 0 (base)
      Active Timer: 3 min
      Distance: internal 90 external 170
      Maximum path: 4
      Maximum hopcount 100
      Maximum metric variance 1

  Automatic Summarization: disabled
  Automatic address summarization: 
  Maximum path: 4
  Routing for Networks:  
     172.16.1.0/24
     172.16.3.0/30
     192.168.10.4/30
  Passive Interface(s): 
    GigabitEthernet0/0
  Routing Information Sources:  
    Gateway         Distance      Last Update 
    172.16.3.2      90            743883     
    192.168.10.6    90            771366     
  Distance: internal 90 external 170

If you want to check out the interfaces on R1 enabled for EIGRP, there’s a simple command for that.

R1#sh ip eigrp interfaces 
IP-EIGRP interfaces for process 1

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Se0/0/0            1        0/0      1236       0/10           0           0
Se0/0/1            1        0/0      1236       0/10           0           0
Ping Test

Let’s do a Ping test on PC1 and see if it can reach PC2 and PC3.

This test will also serve as an end-to-end connectivity check.

PC1 to PC2
Packet Tracer PC Command Line 1.0
C:\>ping 172.16.2.10

Pinging 172.16.2.10 with 32 bytes of data:

Reply from 172.16.2.10: bytes=32 time=1ms TTL=126
Reply from 172.16.2.10: bytes=32 time=1ms TTL=126
Reply from 172.16.2.10: bytes=32 time=1ms TTL=126
Reply from 172.16.2.10: bytes=32 time=1ms TTL=126

Ping statistics for 172.16.2.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 1ms, Average = 1ms

PC1 to PC3
C:\>ping 192.168.1.10

Pinging 192.168.1.10 with 32 bytes of data:

Reply from 192.168.1.10: bytes=32 time=15ms TTL=126
Reply from 192.168.1.10: bytes=32 time=4ms TTL=126
Reply from 192.168.1.10: bytes=32 time=17ms TTL=126
Reply from 192.168.1.10: bytes=32 time=1ms TTL=126

Ping statistics for 192.168.1.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 17ms, Average = 9ms

The two pings from PC1 made it to their destination.

All in all, this lab worked fine and is a good stepping stone to master EIGRP.

How to Configure EIGRP Named Mode Authentication

 EIGRP, Networking, Security  Comments Off on How to Configure EIGRP Named Mode Authentication
Sep 282022
 

Configure EIGRP Named Mode Authentication

In this lab, we’ll configure authentication when running EIGRP in named mode.

While classic mode EIGRP offers only MD5 authentication, named mode EIGRP offers both MD5 and HMAC-SHA-256 authentication.

HMAC-SHA-256 authentication is, of course, the more secure version.

By the way, we can configure authentication between two routers with one running in EIGRP classic mode and the other in EIGRP named mode.

But both would have to use the MD5 authentication mode because EIGRP classic mode does not support HMAC-SHA-256.

Why EIGRP Authentication?

Authentication is essentially a security mechanism to prevent undesirable consequences in the network.

EIGRP router authentication ensures that unauthorized or rogue routers do not become neighbors with other corporate routers.

Unauthorized routers can result in invalid routes and in the worst case scenario lead to data loss or denial of service.

What Our Configuration Looks Like

In our setup, we have three routers: R1, R2 and R3.

All of the routers are running EIGRP in named mode.

Between routers R1 and R2, we’ll be configuring MD5 authentication using a key chain.

Key chain does not need to be same on both routers but the Key ID and Key String must be same for both R1 and R2 routers.

Subsequently, we’ll go in for HMAC-SHA-256 authentication between R2 and R3.

HMAC-SHA-256 authentication can be done both without and with a key chain.

Most HMAC-SHA-256 authentication configurations that I have come across do not include a key chain.

Apparently, the key chain feature is not necessary if you’re going with HMAC-SHA-256 authentication.

Between R2 and R3, we’ll first do HMAC-SHA-256 authentication without a key chain and follow it up by adding a key chain to the configuration.

Following the two modes of authentication, we’ll run a bunch of Verify commands to ensure our goals are met.

Configure EIGRP Named Mode Authentication

We’ve configured the IP addresses on the three routers.

IP addresses have already been configured and you can check them by looking at the topology (see at top of this post).

Once again, all three routers are running EIGRP in named mode.
====================
Configure MD5 Authentication between R1 and R2
R1 Configuration
conf t
key chain ROMEO
key 1
key-string Cisco@123
exit
!
router eigrp TESTING
address-family ipv4 unicast autonomous-system 123
network 10.11.1.1 0.0.0.0
!
af-interface gig0/0
authentication mode md5
authentication key-chain ROMEO
!
exit-af-interface
exit-address-family

R2 Configuration
conf t
key chain ROMEO
key 1
key-string Cisco@123
exit
!
router eigrp NESTING
address-family ipv4 autonomous-system 123
network 10.11.1.2 0.0.0.0
network 10.12.1.1 0.0.0.0
!
af-interface gig0/1
authentication mode md5
authentication key-chain ROMEO
exit
! Configuring HMAC-SHA-256 Authentication between R2 and R3
af-interface gig0/2
authentication mode hmac-sha-256 7 Password@1
exit-af-interface
exit-address-family
exit
!
R3 Configuration
conf t
router eigrp PESTING
address-family ipv4 autonomous-system 123
network 10.12.1.2 0.0.0.0
! HMAC-SHA-256 Authentication between R3 and R2
af-interface gig0/3
authentication mode hmac-sha-256 7 Password@1
exit-af-interface
exit-address-family
exit

As you can see above, we’ve not configured a key chain for HMAC-SHA-256 authentication between R2 and R3.

Verify EIGRP Authentication

Having completed the configurations, let’s run a bunch of verify commands.

Verify MD5 Authentication between R1 and R2
R1#sh ip eigrp int detail gig0/0
EIGRP-IPv4 VR(TESTING) Address-Family Interfaces for AS(123)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi0/0 1 0/0 0/0 1594 0/0 7972 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial
Packetized sent/expedited: 2/0
Hello’s sent/expedited: 92/2
Un/reliable mcasts: 0/2 Un/reliable ucasts: 2/2
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 1 Out-of-sequence rcvd: 0
Topology-ids on interface – 0
Authentication mode is md5, key-chain is “ROMEO”
Topologies advertised on this interface: base
Topologies not advertised on this interface:

Verify HMAC-SHA-256 Authentication between R2 and R3
R2#sh ip eigrp int detail gig0/2
EIGRP-IPv4 VR(NESTING) Address-Family Interfaces for AS(123)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi0/2 1 0/0 0/0 0 0/0 50 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial
Packetized sent/expedited: 1/0
Hello’s sent/expedited: 103/2
Un/reliable mcasts: 0/1 Un/reliable ucasts: 3/3
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 2 Out-of-sequence rcvd: 0
Topology-ids on interface – 0
Authentication mode is HMAC-SHA-256, key-chain is not set
Topologies advertised on this interface: base
Topologies not advertised on this interface:

Check Key Chain on R1
R1#show key chain
Key-chain ROMEO:
key 1 — text “Cisco@123”
accept lifetime (always valid) – (always valid) [valid now]
send lifetime (always valid) – (always valid) [valid now]

Check Key Chain on R2
R2#show key chain
Key-chain ROMEO:
key 1 — text “Cisco@123”
accept lifetime (always valid) – (always valid) [valid now]
send lifetime (always valid) – (always valid) [valid now]

Adding Key Chain on R2 and R3 (HMAC-SHA-256 mode)

R2 Configuration
conf t
key chain JULIET-CHAIN
key 2
key-string Bisco@123
exit
!
router eigrp NESTING
address-family ipv4 autonomous-system 123
af-interface gig0/2
authentication key-chain JULIET-CHAIN
exit

R3 Configuration
conf t
key chain JULIET-CHAIN
key 2
key-string Bisco@123
exit
!
router eigrp PESTING
address-family ipv4 autonomous-system 123
af-interface gig0/3
authentication key-chain JULIET-CHAIN
exit
=================
Verify R2 with HMAC-SHA-256 AND Key Chain
R2#show ip eigrp int detail gig0/2
EIGRP-IPv4 VR(NESTING) Address-Family Interfaces for AS(123)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi0/2 1 0/0 0/0 10 0/0 50 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial
Packetized sent/expedited: 2/0
Hello’s sent/expedited: 1518/3
Un/reliable mcasts: 0/2 Un/reliable ucasts: 5/4Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 2 Out-of-sequence rcvd: 1
Topology-ids on interface – 0
Authentication mode is HMAC-SHA-256, key-chain is “JULIET-CHAIN”
Topologies advertised on this interface: base
Topologies not advertised on this interface:

Verify Authentication on R3 AFTER Adding Key Chain
R3#show key chain
Key-chain JULIET-CHAIN:
key 2 — text “Bisco@123”
accept lifetime (always valid) – (always valid) [valid now]
send lifetime (always valid) – (always valid) [valid now]