We lost some SAN disk, which meant we had to fail over to our DR site. Our web servers was brought up, and now they were communicating over OTV with the SQL server cluster (which was not affected). The response was horrible, and with wireshark I could see some retransmission etc, but not excessive. So we decided to also fail over SQL servers to the DR site, and all worked good. Also, our VMWare VCenter clients has absolute horrible response when it was talking to the VCenter DB, which is MSSQL, at the DR site. There is ample bandwidth (500Mbps) of which abour 125Mbps was used, and voice, which also runs on the line is fine. The rest of the virtual machines was fine.
I know NLB has issues with OTV, but have anyone experienced similiar problems with SQL?
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...