This KB article provides a brief explanation of the logical PIME and PIMD interfaces on multicast implementation using PIM Sparse Mode.

Symptoms

• What are the PIME and PIMD interfaces in multicast ?
• Are they manually configured or automatically instantiated by the system?
• How do these interfaces handle encapsulation and decapsulation of multicast traffic?
• What is the process by which multicast packets are encapsulated into PIM Register messages and how they are decapsulated at the RP?
• How can we verify the status and operation of the PIME and PIMD interfaces?

The PIME (PIM Encapsulation Interface) is used by the Designated Router (DR) to encapsulate multicast packets into PIM Register messages and send them to the Rendezvous Point (RP) and the PIMD (PIM Decapsulation Interface) is used by the RP to decapsulate the PIM Register messages and extract the original multicast traffic.

A PIM register message is used by the First Hop Router (FHR)—the router directly connected to the multicast source—to encapsulate multicast packets and send them to the Rendezvous Point (RP). This happens when a new multicast stream begins and the RP has not yet built a native multicast forwarding path to the source.

How do they Work?

1. Multicast Source Sends Traffic → The DR receives multicast packets.
2. Encapsulation → The DR uses the PIME interface to encapsulate the first multicast packet in a PIM Register message.
3. Unicast Tunnel to RP → The encapsulated packet is sent via a unicast tunnel to the RP.
4. Decapsulation → The RP uses the PIMD interface to decapsulate the packet and forwards it down the multicast tree.
5. This mechanism ensures that multicast traffic reaches the RP even before the multicast distribution tree is fully built.

NOTE: These interfaces are automatically created.

In the following PCAPs and outputs, we’ll observe how a source Designated Router (DR) with loopback address 192.168.100.10 sends a PIM Register message through its PIME interface. This interface acts as a tunnel to encapsulate multicast traffic and forward it to the Rendezvous Point (RP), which has the loopback address 192.168.100.30. The multicast group in question is 239.255.100.15:

The "pime" interface is responsible for encapsulating multicast traffic into unicast packets, which you can observe on the Source DR:

root@SourceDR> show pim interfaces

Stat = Status, V = Version, NbrCnt = Neighbor Count,

S = Sparse, D = Dense, B = Bidirectional,

DR = Designated Router, DDR = Dual DR, DistDR = Distributed DR,

P2P = Point-to-point link, P2MP = Point-to-Multipoint,

Active = Bidirectional is active, NotCap = Not Bidirectional Capable

Name              Stat Mode IP V State       NbrCnt JoinCnt(sg/*g) DR address

irb.20            Up  S    4 2 DR,NotCap        0 0/0           192.168.20.1

pime.32769        Up  S    4 2 P2P,NotCap       0 0/0

xe-0/0/0.0        Up  S    4 2 NotDR,NotCap     1 0/0           172.16.1.1

xe-0/0/1.0        Up  S    4 2 DR,NotCap        1 0/0           172.16.1.9

Multicast traffic encapsulated on the Register unicast message going towards RP (192.168.100.30).

The "pimd" interface is responsible for decapsulating unicast traffic into multicast packets, which you can observe on the RP:

root@RP> show pim interfaces

Stat = Status, V = Version, NbrCnt = Neighbor Count,

S = Sparse, D = Dense, B = Bidirectional,

DR = Designated Router, DDR = Dual DR, DistDR = Distributed DR,

P2P = Point-to-point link, P2MP = Point-to-Multipoint,

Active = Bidirectional is active, NotCap = Not Bidirectional Capable

Name              Stat Mode IP V State       NbrCnt JoinCnt(sg/*g) DR address

pimd.32769        Up  S    4 2 P2P,NotCap       0 0/0

xe-0/0/1.0        Up  S    4 2 DR,NotCap        1 0/0           172.16.1.3

xe-0/0/2.0        Up  S    4 2 NotDR,NotCap     1 0/0           172.16.1.5

Multicast traffic is decapsulated by the Rendezvous Point (RP) before being sent downstream to the receivers.