rssLink RSS for all categories
 
icon_red
icon_green
icon_red
icon_red
icon_blue
icon_green
icon_green
icon_red
icon_red
icon_red
icon_orange
icon_green
icon_green
icon_green
icon_green
icon_blue
icon_green
icon_orange
icon_red
icon_green
icon_red
icon_red
icon_green
icon_red
icon_red
icon_red
icon_red
icon_orange
icon_green
 

FS#8211 — FS#12082 — vrack1.5

Attached to Project— Dedicated servers
Incident
Associated service
CLOSED
100%
We have a problem with the Vrack between
RBX and 3 other datacenters : SBG, GRA and BHS.
We are investigating the cause of the problem.

The impacted customers have the Vrack between
the DC.
Date:  Sunday, 23 November 2014, 08:09AM
Reason for closing:  Done
Comment by OVH - Saturday, 22 November 2014, 14:31PM

We are working with the equipments manufacturer
to find the origin of the problem.
The vrack inside RBX is still working. The vrack
in the other DC is still working and between the DC.
The problem is at the level of the equipments at Roubaix
which were isolated from the vrack network and continued
to work normally on the IPv4/IPv6. We are searching
the origin of the problem.


Comment by OVH - Saturday, 22 November 2014, 15:28PM

We are studying the problematics of change of the configuration
since this night to find the origin of this problem.
The TAC of Cisco is on this problem too.


Comment by OVH - Saturday, 22 November 2014, 15:29PM


It is possible that we have the bug CSCug87873 .
There is a patch. We look at the application conditions
of the patch (reload or no reload)


Comment by OVH - Saturday, 22 November 2014, 15:47PM

#run attach 0/RSP0/CPU0
sysmgr_control -A -r udp

to relaunch the process


Comment by OVH - Saturday, 22 November 2014, 15:47PM

The problem seems to be fixed.

We check.


Comment by OVH - Sunday, 23 November 2014, 08:09AM

After the first restart of udp process, everything is back in order.Then we looked for the network stream triggering the problem. After 2 hours the UDP process had already returned to 50% of its max memory usage but by analyzing the packets going back to the CPU, we could identify the flow issue accurately. So we could add the required filtering to prevent that this flow goes back to the router cpu and fix the problem permanently.