This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

IP SLA on Layer 2 WAN links

My remote sites are connected via carrier ethernet, and layer 2 interfaces on various Cisco switches. I do not have routers at the locations. Is it possible to run IP SLA?

  • If you do not have L3 interfaces / routers at the other end, what are you expecting to monitor ?
  • I guess that is the point of my question. Is VOIP monitor a fit for my setup. Although the remote site is connected via layer 2, I still have a phone system and IP phones that need to contend for BW on the WAN link. I'm having some voice quality issues, and I'm looking for a way to monitor it.

  • I believe achrich is right, in that ip sla uses layer 3.   Also, if your talking about cisco switches, that the native Cat ios does not support ip sla.   I could be wrong,


  • Can you provide any detail on the kit your using to terminate the L2 ? If its a 4/6xxx Cisco switch you may be able to do some manual monitoring with it but you`d get more value if your running it on a router.

  • I have a cisco 3750 stack at the remote site. It is connected to a Cisco 6509 sup 2 via a 10M carrier ethernet circuit. The connecting interfaces are configured as 802.1Q trunks.


     Thanks. 

  • You might want to consider that the devices running the WAN links do not need to be the the ones creating and running the SLAs for VoIP monitor. 


     I use an older 7204 and a 2811 as two nodes that do little else but act as SLA Hubs endpoints for now...  It just needs local Ethernet connectivity and a current enough IOS and RAM capacity that can support the Cisco IOS SLA features...


    No real need to worry about the L2 vs L3 issue across the trunks as far as the SLAs go.  You just need two or more devices that sit on opposite sides of the links in question.  VoIP monitor will use them as VoIP call simulators to validate the call quality across the link.  VoIP Monitor will not tell you where the problem is, only between which SLA devices there are problems... or not... as the case may be...  The endpoints can be in the same L3 subnet or not, as it doesn't matter.


  • From what I can see, the only switches that Cisco's Feature Navigator seems to indicate supports the VoIP/Responder features are the 3560/3750 with IOS v12.2(40)SE.  I have not tried them with VoIP Monitor just yet myself though...

  • Using a non-core device as the SLA responder has several advantages.

    Orion and VoIP Monitor have more frequent updates than might want to subject your core Cisco devices to.

    VoIP monitor it is MUCH easier to monitor the links if it is given SNMP Write access to the SLA devices.  This can be a bit risky in case Orion or the IOS in the device causes a problem when adding/removing SLA responders with the production core switches or routers.  Having separate units for SLA only risks your stats gathering, not production traffic...

    You already monitor the switches and links and so dropped packets and such will be in Orion for many of the L2 issues.

    The VoIP devices (phones, call handlers, etc..) you have deployed are not the core switches themselves anyway, so it is the ability to carry the VoIP traffic between the sites which is the aspect you are interested in, not specifically which device is doing the testing...

     

    As a side note, one important thing to keep in mind with Ethernet WAN connections is that the port speed for say a 10M link should be locked to 10M/Full duplex on both sides and both ends, otherwise the basic QOS for the Cisco switches will not work correctly.  If the Carrier link you use negotiates a 100M speed for example, but only forwards 10M of data, traffic >10M will just drop out on the floor.  If it is not 10M or 100M like the port physical speed, (say 25M) things get more complicated to configure for QOS and flowcontrol, but can be done as well.