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.
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.
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...
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
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 ;-) )
This document is an early notification of a behaviour change that will be introduced in IOS XR release 6.5.
IOS XR configuration principles relevant for this article are:
On router platforms all interfaces must be by defaul...
With XR 4.2.0 the ASR9000 is releasing a new line of hardware models. This amongst others is the RSP440, the next generation RSP with faster switch fabric along with Typhoon based Linecards, the next generation network processor.
The Cisco EPN system incorporates a network architecture designed to consolidate multiples services on a single Multiprotocol Label Switching (MPLS) transport network. This network is designed primarily based on Application ...