Big problem: Bstun async and TCP IP frame size

snipped-for-privacy@hotmail.com skrev:

I have no idea how to do what you ask.

Not entirely sure what you need but maybe these suggestions can help?

-SAto

First of all, thank you very much for your quick answer

SAto ha escrito:

Imagine the scenario I described before. What I want to do is to map every byte received at the Serial0/0/0 of the first router Cisco 2811 to the Serial0/0/0 interface of the second router Cisco 2811.

This can be done thanks to BSTUN tunnels. As there is no local-acknowledge protocol in the interface Serial0/0/0 (in order words, I am receiving a constant byte flow which I must forward to the other router) I have no more option than configuring the protocol "Async-generic". So there is neither address byte nor start-of-frame byte. As I have said before, the only thing I have is a incoming bytes flow entering the router through the Serial0/0/0.

So the router is in charge of collecting these bytes, encapsulate them in a BSTUN TCP/IP packet and send this packet to the other peer, where it will be deencpasulated and the data bytes will be forwarded to the Serial0/0/0 interface of the second router.

the problem I have is that I haven't found out if there is a parameter that controls the number of data bytes encapsulated in each BSTUN TCP/IP packet. I would like to set it to 1000 bytes or so.

Thanks, but I am afraid that it doesn't solve my problem... but thanks for the link!!

Victor,

I think you'd be better off switching from using BSTUN async and going to stream TCP tunneling instead:

Try it with default settings; if you still feel the need to tune, here are some line knobs that you can wiggle:

buffer-length ip tcp input-coalesce-threshold dispatch-timeout

Regards,

Aaron

Aaron Leonard ha escrito:

Thank you Aaron for your contribution!!

But After reading the article, it gives the impression that some kind of local acknowledge or call control mechanism through the RS-232 line is performed by means of sending "CR" and "LF" characters. I am using Hyperterminal because it is the easiest and quickest way to simulate the real device who will send this byte flow through the RS-232 link to the router. This device doesn't admit any connection control character at all.

Moreover, it strikes to me that this approach is more suitable for a scenario where one of the routers generates more traffic in one direction than in the other. However, in the scenario I have to test, both directions are equally loaded.

One more question: the aim of the configuration of these two routers is mapping several async interfaces in one router with the same number of async interfaces in the final router:

Serial0/0 (Router 1) Serial0/0 (Router 2) Serial0/1 (Router 1) Serial0/1 (Router 2) Serial0/2 (Router 1) Serial0/2 (Router 2)

and so on.

I don't see any identifier number similar to "bstun group" parameter in order to perform this mapping. Am I wrong?

Anyway, thank you very much for your reply!!

~ ~ Aaron Leonard ha escrito: ~ ~ > Victor, ~ >

~ > I think you'd be better off switching from using BSTUN async and going ~ > to stream TCP tunneling instead:

>

~ ~ Thank you Aaron for your contribution!! ~ ~ But After reading the article, it gives the impression that some kind ~ of local acknowledge or call control mechanism through the RS-232 line ~ is performed by means of sending "CR" and "LF" characters.

Not necessarily. "stream TCP" is just raw TCP, with no EOL convention.

~ I am using ~ Hyperterminal because it is the easiest and quickest way to simulate ~ the real device who will send this byte flow through the RS-232 link to ~ the router. This device doesn't admit any connection control character ~ at all. ~ ~ Moreover, it strikes to me that this approach is more suitable for a ~ scenario where one of the routers generates more traffic in one ~ direction than in the other. However, in the scenario I have to test, ~ both directions are equally loaded.

Raw TCP is perfectly capable of handling full duplex traffic.

~ One more question: the aim of the configuration of these two routers is ~ mapping several async interfaces in one router with the same number of ~ async interfaces in the final router: ~ ~ Serial0/0 (Router 1) Serial0/0 (Router 2) ~ Serial0/1 (Router 1) Serial0/1 (Router 2) ~ Serial0/2 (Router 1) Serial0/2 (Router 2) ~ ~ and so on. ~ ~ I don't see any identifier number similar to "bstun group" parameter in ~ order to perform this mapping. Am I wrong?

On the "calling side" line, target the desired "called side" by connecting to the TCP port 4000 + line number.

Best regards,

Aaron