09-03-2013 11:49 AM
I have read the documentation for v5.2 configuration and can't find an answer to my question.
We have several MLX4s and MLXe4s which are configured to be sntp clients. These MLXs are configured with VRFs. There are devices in the network which require NTP services and get their time from a dedicated NTP server, which is connected to the MLX. These devices are configured in one of the VRFs, which required connecting the NTP server into this same VRF as well. The devices get their time successfully. However, the MLX itself can no longer get NTP service because, apparently, the MLX can only get NTP service on the Default VRF. I didn't find this documented anywhere, but it seems to be the case. Due to this, I have had to create a separate dedicated connection to the NTP server, configured in the Default VRF. So, there are separate interfaces for NTP in both the Default VRF, and the VRF in which the other devices reside.
This seems to be a crappy way to set this up, and I can't help but think I must be missing something.
Can someone offer a better solution, such that I can provide NTP to the MLX as well as all the connecting devices which need NTP? Also, is there some documentation I missed or just didn't understand?
Thank you in advance,
09-04-2013 05:42 AM
Your problem seems odd. Afterall, NTP traffic is fairly straightforward and one of the oldest protocols we use. I can't see why an MLX series device would only want to forward that specific traffic type through one particular VRF. The only comparison I have is with our CER series. Currently I have NTP updating through the mgmt port. However, I did have it updating through a virtual interface outside of the default vlan.
Why are you using SNTP vs NTP? I mean, the difference between both of them is very miniscule. The difference is error checking and the time correction if I remember correctly. Can you do a source ping from the vrf interface to your time server? Can you telnet to the time server on the appropriate port? Have you tried running a packet capture to further confirm if the NTP traffic is comming from the MLX to your time server?
09-04-2013 08:20 AM
Thanks for your reply. The problem isn't with the protocol itself, I believe it has to do with which VRF can be configured as an NTP client. Apparently, only the default VRF can be configured as an NTP client. After a few more searches in this KB, I found a couple of questions/answers similar to mine. I hope these links work:
So, if I want the MLX to get NTP, it must access the NTP server via the default VRF. All other network elements that need NTP must access the NTP server via the VRF they are configured in. Since I can't use inter-VRF routing, this becomes very cumbersome, requiring a separate interface/connection to the NTP server for each VRF. I thought, for sure, I was doing something wrong, but it seems this is by design.
I am using SNTP because that seems to be all that is available in v5.2. Looks like 5.4 might have NTP, but we're not there yet.
09-04-2013 02:44 PM
I missed a very important piece of your original post. Unfortunately I have been in SBC mode as of late and it just didn't click in. What you are concerned with is route-bleeding across your VRFs. Make sense that you can't route in between but at the same time a pain in the rear when you are trying to have some services work in between vrfs, in your case NTP.
A workaround I once used (not with brocade) was a GRE tunnel from one VRF to another. I would then bleed specific subnets across. Though I have yet to find this as "supported", it does work. In your case, you would be able to bleed a /32 to your VRFs and have each of 'em update to your time server. I used iBGP.. you could use OSPF or static really...
This is just a suggestion....again I have yet to try this with the Brocade product line. However in theory it should work.