DX Application Performance Management

 View Only
  • 1.  TIM and RSPAN in CISCO ACI

    Posted Jan 07, 2020 04:47 PM
    Hello team,
    
    CA APM with TIM is currently being implemented.
    The client has cisco aci, and we wanted to know if the implementation of RSPAN under cisco aci is feasible, and if so, there is some documentation that they provide.

    Richard


  • 2.  RE: TIM and RSPAN in CISCO ACI

    Broadcom Employee
    Posted Jan 09, 2020 02:52 PM
    @Jörg Mertin Can you help on this one? ​

    ------------------------------
    Custom Solution Architect
    Broadcom
    ------------------------------



  • 3.  RE: TIM and RSPAN in CISCO ACI

    Posted Jan 09, 2020 07:19 PM
    Hi Team,

    What consideration at the frame level or other parameter should be taken into consideration when configuring the span port on a Cisco aci.

    Thanks,
    Richard



  • 4.  RE: TIM and RSPAN in CISCO ACI
    Best Answer

    Broadcom Employee
    Posted Jan 10, 2020 03:44 AM
      |   view attached
    Well, with today's data-volumes, you should avoid anything that uses SPAN/RSPAN to feed data to TIM's. The Problem is not the volume per se, but the quality of the traffic that will reach the TIM. You should have a look at the attached document I had written ages ago on that precise topic.
    That being said, the TIM has no issues with handling SPAN/RSPAN traffic if it is "clean". Nothing special needs to be done.

    Be sure you do not feed any type of GRE to the TIM. As the TIM will simply discard it (it can't decapsulate it).

    If, after all these "warnings" the customer still wants to go with RSPAN/SPAN, make sure the switches are not over subscribed, the CPU of these switches is not loaded to prevent any type of packet drop from the source or heavy misalignment. And make sure they SPAN the traffic of one only port on the switch to avoid traffic replications of various possible VLAN's.

    Attachment(s)



  • 5.  RE: TIM and RSPAN in CISCO ACI

    Posted Jan 19, 2020 12:19 AM
    Hi Jörg,

    Thanks,
    Richard