IP SLA port

Unanswered Question
Nov 10th, 2009


Just a quick clarification. We use IP SLA product with a router configured as the SA agent(with ip sla monitor responder enabled) and use our SNMP Management station (Concord) to measure/take the stats from the routers and display accordingly. However, all the SA Agents (Customer CPE) have now moved behind a 3rd party maintained firewall. I need to open up this firewall but am unsure of the direction of the traffic flow.

So, I think it uses UDP Port 1967 but can you tell me if the SNMP Concorde Station polls the SA Agents/Customer CPE with UDP port 167 as destination?

dunshaughlin_PE14_dub>sh ip sockets

Proto Remote Port Local Port In Out Stat TTY OutputIF

17 0 1967 0 0 211 0

17 0 2067 0 0 100001 0

17 162 50646 0 0 0 0

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Joe Clarke Tue, 11/10/2009 - 08:52

Concord is doing all of the polling using SNMP. That port is udp/161. The destination port will be udp/161, and the source port will typically be an ephemeral UDP port.

maryodriscoll Tue, 11/10/2009 - 09:04

According to SAA Control Protocol documentation that we received from Cisco, the SAA Control protocol uses udp port 1967 when warning the responder that the sender is going to start the probe...I thought the sender was Concorde?

Joe Clarke Tue, 11/10/2009 - 09:12

No, Concord should just be doing the configuration and polling on an IP SLA source device. It is the device itself that does the actual probes.

maryodriscoll Tue, 11/10/2009 - 09:51

So, Concorde polls the devices using SNMP as per standard and captures the data? Sorry about all this but I just want to be absolutely sure....

Joe Clarke Tue, 11/10/2009 - 10:13

Yes, that is my understanding. I do not know of any third party applications that act as true IP SLA sources.

maryodriscoll Thu, 11/12/2009 - 06:34

Back again, I've just been onto the Concorde support people.

They have come back to me confirming that there concorde server can communicate via Port 161 to both the SAA Source and SAA Destination. The SAA Destination where the Responder command is enabled( can ping the SAA Source( However, Concorde are insisting that I need to confirm that the SAA source and SAA Destionation SLA app are communicating with each other.

I can successfully ping between each other but the ACL 111 I have enabled on both ends is not picking anything up even though Concorde is setup to poll every 62 seconds? My access-list 111 which I am debugging is

SAA_Responder_dub#sh access-list 111

Extended IP access list 111

10 permit icmp host host

20 permit icmp host host

30 permit ip host host

40 permit ip host host


Any ideas or should I raise a TAC?

Joe Clarke Thu, 11/12/2009 - 09:36

The source and destination do not need to communicate with each other with SNMP. They will communicate via the configured IP SLA operations. You haven't said what these operations are, so I'm not sure if communication is possible. However, this ACL is wide open for both the source and I guess the Concord manager, so I don't really see a problem. Without seeing the whole config, though, I cannot say for certain if a problem exists.

maryodriscoll Fri, 11/13/2009 - 01:33

Sorry, I'm confusing you here...The ACL is just for debugging purposes. We have nothing configured on these routers...the concorde server is configured with all the parameters. The only parameters configured here is ip sla monitor responder on the SAA Responder with nothing on the SAA Agent. I have been told that is all that is required? I've enabled the ACL 111 just generally to see if I catch anything on the control port but nothing!! This was working, no acl/firewall between the 2 nodes so stumped....Any ideas?

Joe Clarke Fri, 11/13/2009 - 08:22

Concord will configure the source device via SNMP, so the IP SLA config may not show up in the running config. You can look at the output of the show ip sla monitor config and collection commands to see if the collectors are configured and working. Without seeing the full configs of the devices, and without knowing exactly what IP SLA operations you are using, and without knowing exactly what problem symptoms you're seeing I cannot offer more insight.


This Discussion