• Enabling Passive/Transparent Devices for PTP Multicast Routing

 
 
Print Friendly, PDF & Email

Why is PTP Multicast Routing Needed?

PTP is a highly precise time protocol, the best practice for PTP is to introduce devices as PTP-Transparent (vs Passive) if the device is L3 and does not act as Boundary Clock. Any introduction of PTP-Passive devices in the path reduces the accuracy of the protocol. Both Transparent and Passive devices require additional configuration in order to forward the PTP stream. If a device must also manage a control-plane flow (and hence has a dependency on the control traffic), this can also reduce the accuracy of PTP.  Due to this, and as the capability for a PTP node to send Joins/Reports is not included in the IEEE specification (1588-2008), the Arista distribution of PTP does not send IGMP reports or PIM joins from enabled nodes. This means that when there are L3 devices in the path that are not configured as Boundary Clocks additional configuration is necessary to complete the multicast flow.

Where Are Static Joins Required?

When working with a standard multicast application IGMP and PIM are relied upon to dynamically manage where the stream is forwarded. Since Arista PTP nodes do not send IGMP or PIM joins, static configuration must be applied to ensure the stream propagates properly. The static configuration is required on an L3 interface where the PTP traffic must be routed. There are four main things that should be considered when determining where this static configuration is required:

  1. Where/how is the Grand Master (GM) connected?
  2. Where/how are Boundary Clocks (BC) connected?
  3. What is the method of transit between the GM, BCs, and slaves?
  4. What dependencies exists to ensure this traffic flow?

Examples

Scenario 1

  1. The GM is connected to passive device Edge-1 on Vlan10.
  2. The BC is connected to passive device Edge-1 on Vlan12.
  3. The multicast stream must ingress access port Eth2 in Vlan10, then be routed into Vlan12 to be forwarded out Po12 to BC-2 where it will be processed by the Boundary Clock.
  4. To ensure that stream is routed from Vlan10 to Vlan12 BC-2 must send an IGMP Join in Vlan12 to Edge-1, so that Edge-1 will populate Vlan12 in the OIL.

 

In this straightforward topology, we only need to configure 1 static entry to ensure the flow from GM to BC, as there is only 1 BC attached via a passive hop between the GM and BC. The static group should be configured on the DR for the LAN, in this scenario BC-2 is the DR for Vlan12 (and Edge-1 has the only L3 interface for Vlan10). To get this flow to work the following configuration must be added on BC-2:

interface Vlan12
    ip igmp static-group 224.0.1.129

If the GM server also does not send dynamic joins it may also be necessary to add the following on Edge-1 so that the return path (BC -> GM) will also be functional:

interface Vlan10
    ip igmp static-group 224.0.1.129

Scenario 2

If we add additional routers to the LAN, additional configuration is needed. When a topology is configured with redundant SVIs which could become DR in failover scenarios it would be recommended to have the static-group configured on both. This way PTP can continue to be forwarded should the DR failover. In the topology below each BC is connected on a dedicated Vlan such that Vlan11 is shared only between Edge-1 and BC-1, and Vlan12 is shared only between Edge-2 and BC-2.

  1. The GM is connected to passive device Edge-1 via Vlan10.
  2. There are two BCs in this topology:
    1. BC-1 is connected to passive device Edge-1 via Vlan11.
    2. BC-2 is connected to passive device Edge-2 via Vlan12. Edge-2 is then connected to Edge-1 via Vlan10.
  3. There are two PTP flows in this topology:
    1. The multicast stream for BC-1 will ingress access port Eth2 on Vlan10, and then will be routed to Vlan11 to be forwarded out Po11.
    2. The multicast stream for BC-2 will ingress access port Eth2 on Vlan10 and be forwarded out Po1 to Edge-2. Edge-2 will then route the traffic into Vlan12 to be forwarded out Po12.
  4. Each flow has its own dependencies:
    1. To get the traffic to BC-1 we need to ensure that Vlan11 is populated in the OIL for 224.0.1.129 of Edge-1.
    2. To get the traffic to BC-2 we need to ensure that Vlan10 is populated in the OIL for 224.0.1.129 of Edge-1 (such that Edge-2 can receive the source stream for PTP) AND we need to ensure that Vlan12 is populated in the OIL for 224.0.1.129 of Edge-2.

In this scenario, we have 2 BCs, and an additional passive hop. In total, this will require 3 static entries to get the flow to both BCs:

BC-1

interface Vlan11
    ip igmp static-group 224.0.1.129

Edge-2

interface Vlan10
    ip igmp static-group 224.0.1.129

BC-2

interface Vlan12
    ip igmp static-group 224.0.1.129

Edge-1 (If GM does not send joins)

interface Vlan10
    ip igmp static-group 224.0.1.129

The above configurations will ensure that the GM can reach all BC devices, and devices which respond to GM via multicast will have a reverse path available (additional configuration may be required to ensure redundancy). The same considerations should be made for paths between BCs and slave devices. If any slave devices exist which must subscribe to PTP, but also do not send IGMP reports at L2 then a static snooping entry must also be in place at the access layer:

AcecessSwitch(config)#ip igmp snooping vlan <#> static 224.0.1.129 interface ethernet <x>

Please keep in the mind that having any L3 PTP-Passive devices in the path is considered sub-optimal, and it is recommended to configure L3 hops as Transparent Clocks whenever possible. For additional questions please contact Arista TAC at support@arista.com.

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: