Hi,
first i think if fst does work but tcp does not than you should make an extra effort to understand why tcp does not work.
Take a sniffer trace from the attempt to bring the peer up. Do the debugging on both routers simultaneous.
debug dlsw peer
debug ip tcp driver
debug ip tcp transactions
to start. If you need help in troubleshooting and to interpret the debugging open a case with cisco tac.
The difference between tcp and fst peers is like this:
tcp has a tcp session between the two routers. it does do segmentation of large frames from the lan over a wan with a lower mtu. I.e 4k tokenring frames over a wan media with mtu 1500.
Tcp peers do local ack on the local llc2 sessions,
that means llc2 RR frames are locally acked and do not go over the WAN.
fst:
fst has no tcp session between the two peers. It does NOT do segmentation of large lan frames over a wan with a smaller mtu.
fst does NOT do local ack, llc2 RR frames are end to end.
Typically you need to configure the lf parameter on the remote peer statement for a fst peer. I.e. lf 1500 if you connect ethernets. Also you need to make absolutely sure that your WAN can carry a maximum ethernet frame + ip header (20 bytes) + fst header (12 bytes). If your WAN mtu is also 1500 and you get a maximum ethernet frame, say 1500 bytes, this will fail since you must add the extra headers, with fst there is no segmentation so every frame send individualy with the extra encap bytes attached to it.
So in this case you need to make sure that your WAN mtu is large enough. If it is a serial line or frame relay you can simply raise the mtu to 1600.
fst is typically used when you have a high bandwidth WAN media. In a scenario where you dont need local ack. If you have low bandwidth frame relay circuits than you can run into timeout situations without local ack.
fst is less cpu intensive than tcp. A good portion runs in the fastswitching path.
thanks...
Matthias
