We are having issues with one-way packet loss after introducing a GRE Tunnel. It is a satellite 1Mb connection, and we are running a video conference over this. One end of the connection is completely fine, but in one direction of the call there is high packet loss leading to dodgy sound and pixelated video. We have a queuing set up on both ends exactly the same, based on the VC IP address. The queue is double the size of the actual call rate which is established (384kbps). No drops from this queue into the default queue seem to be occurring (until we made the queue have a priority of 768, packets were still being dropped from the queue). The side with the packet loss is the more heavily utilised, but i would of though the queuing should take care of it. In between in our routers (Cisco 3745's) at either end, there is the service providers routers. What check can i have them do? Presumably, once the traffic leaves our router, the service providers traffic will simply serve the GRE traffic all the same. But as our routers should be servicing the VC traffic first, then the service providers routers will get this traffic first anyway.
Any steps you coul advise me to take to nail this.
[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...