PTP slave on ASR9000

[Christoph]

Hello all,
I'm currently trying to implement PTP on a couple of ASR9000 but facing some maybe comprehension problems.
I've a setup like this for Circuit Emulation:

ASR901 --(Ethernet-Leased-Line)-- ASR9K --SyncE-- ...

Obviously, the above picture is a bit simplified.
ASR901 is the PTP master and what I'm trying to accomplish is to bridge the frequency synchronization gap of the leased line with PTP.
So the ASR9K is going to be PTP slave and clocks the SyncE lines with the frequency recovered by PTP.

The issue I have is to understand the way PTP is implemented on the 9K.
As per configuration guide, PTP is configured at an interface level (and probably uses that interface IP as source for the PTP session?) as opposed to the regular IOS where you configure an actual PTP process and link it to a dedicated loopback interface.

At first sight, the 9K-way doesn't make a lot of sense to me because:
- Which interface should I choose for the session?
- Should I configure one session per potential interface?
- What happens if an interface goes down?
- How to implement that with prefix-suppression?

Configuring PTP at a loopback interface is not possible, there is no PTP command.

The configuration guide is not really helpful here and I wasn't able to find any real information regarding implementing PTP on the ASR9K.
So I'm hoping that maybe somebody here has already done something similar and can clear this up a bit.

Thanks,
Christoph

[xthuijs]

hi christoph, I'll forward your comment on the PTP config guides to our doc team to see if we can beef that up a bit.

As for the config, here are a few pointers:

Also ref this: https://supportforums.cisco.com/document/133781/asr9000xr-frequency-synchronization

not PTP specific, but many useful commands and some extra explanations hopefully...

Sh freq sync sel

Sh pt int brief

Sh ptp for

Sh ptp pa <int>

Sh ptp pla ser

interface TenGigE0/2/0/5

 ptp

  transport ipv4

  port state slave-only

  master ipv4 192.168.52.38

  !

  sync frequency 64

  announce timeout 2

  delay-request frequency 64

 !

 ipv4 address 192.168.52.41 255.255.255.0

Whatever clock the a9k DTI is sync'd to can, or actually will be used as syncE clock to those configured interfaces when xmitting.

does this get you started?

regards

xander

[Christoph]

Hi Xander,

yeah, I was already aware of that & the actual configuration.

The thing is that the PTP implementation on the 9K differs largely from the normal IOS (interface based vs global process - kinda ironic, btw.) which makes me scratch my head:

First issue is, that the ASR901 have a limited number of PTP slave sessions they can serve, I believe it's 36 currently. So if I'm using one session per potential 9K-interface, I might run into issues at the 901-side.

Next issue is, that we're using IGP prefix-supression, so there is no route for interface /30s and PTP won't sync. Solvable, of course (redistribution, f.e.), but ugly.

So that makes me think, that either this use case was never considered or I'm missing something here. Because it doesn't make a lot of sense to me to run n-times PTP sessions from n-times interfaces of the _same box_ to the _same master_ just for redundancy reasons (which is just interface redundancy).

Bottom line: I'm questioning the interface-based PTP implementation of the 9K.

Regards

Christoph

[xthuijs]

hi christoph,

i think in the current design you have you're always stuck with some sort of interface based approach since if you have multiple possible servers (being the 901's) then they need to be added to some sort of priority list, but I hear you, it has been an implementation decision that we chose based on inputs from those providers that were going to use this 1588 stuff, so it is not that we deliberately try to make it unnecessarily difficult :)

I am thinking maybe an alternative... is it a possibility to make the a9k the timing master by leveraging a gps or something like that and distributing the timing to the 901 instead?

ls that something usable?

I'll discuss this with our timing folks also to see if there is soemthing that can be used or done to ease this out, but regardless of that, it is probably a release or some out if it could change and you'll likely need a solution today I assume, so trying to see if there are alternatives possible...

regards

xander

[Christoph]

Hi Xander,

yeah, if you need PTP just on a local segment it makes totally sense. :-)

Since the 9K is located in an underground data center, GPS is not an option.

What I've omitted in the picture is, that the CEM destinations are also 901's - they're a few hops behind the 9K. So for now, I'm gonna "ignore" the 9K in regards of clocking and solve it with PTP end-to-end.

From a PTP standpoint, it's not the best solution since the goal is always to reduce the number of intermediate non-PTP-aware hops, but I'm pretty sure it will work...

Just for your reference, here's a IOS slave configuration from a 901 with 2 masters:

Router#sh run | sec ptp
ptp clock ordinary domain 4
 clock-port SLAVE slave profile g8265.1
  transport ipv4 unicast interface Lo9000 negotiation
  clock source 192.168.0.80
  clock source 192.168.0.81 1
Router#
Router#sh run int lo9000
Building configuration...

Current configuration : 97 bytes
!
interface Loopback9000
 description PTP ToP0/12
 ip address 192.168.0.98 255.255.255.255
end

Router#

I'm not expecting this to be solved with the next release or so, but it's good to hear the way it's currently implemented was done for a specific reason outside of my use case and that somebody is picking up my points. (even if it doesn't help me right now, but at least I've a plan B ;-) )

So thanks for your answer & efforts anyway!

Regards

Christoph