If I ping the tunnel destination from a router, I get a return time of about 700ms, but pinging the the tunnel end itself returns about 1200ms. I am wondering if the tunneling encryption is adding more bandwidth, causing the higher delay. I have not configured any special thing apart from the tunnel ip address, the source and the destination addresses.
This is normal behavior for a ping, If you ping your own interface on any circuit the ping will travel to the remote side of the ciruit then comes back . If you ping the remote side the ping time will be 1/2 the response as if you your own interface , try it on any wide area link .
I am pinging the remote interface in both situation. The difference is that when I ping the remote tunnel interface, the return time is usually higher than when I ping the remote serial interface (which is the tunnel destination). I am beginning to wonder if there is any kind of checksumming necessary, or something additional I need to configure.
I am right now wondering whether the MTU size can affect it. The tunnel passes over different routers, which have ethernet, fastethernet and serial interfaces. The MTU on the Tunnel is 1476 (default) and the MTU on the ethernet along the link is 1500 while the serial is also 1500. Could this bring a perofrmance issue.
Don't forget these tunnelas are just virtual pipes , the best way to TS is to do a tracerouter to the tunnel dest sourcing it from the tunnel source , you may be traversing more hops than you realize, look for overutilized WAN links and speed /duplex mismatches on lan links
You can massage the routing between the tunnel source and dest to try to reduce the hops or you could use differnt source & dest tunnel ip's that travers less hops , or you can reduce the traffic on the Wan.
[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...