You wrote:
] O.K. I've investigated some more tunneling options based on
] my reading that ALTQ supports the tun0 device. Here is what
] I came up with so far:
]
] 0) KAME IPsec tunnel mode: +STANDARD, +KAME, -ALTQ based on TOS only,
] -doesn't work for me yet, +Cisco interoperable (at least if
] I also use IKE/racoon.)
...
I guess your problem is that you want to use the QOS features
of ALTQ, but you can't do that because your payload is already
opaque, so you can't recover the information?
I suggest you tunnel the packets, like so:
Magic application
| ,--------------.
| | ,-. ...> ,-. |
| | | | | | |
| | | | | | |
| `-|-|------|-|-'
v | | | |
| | | | |
`---()----' `--()--' `-----()----> (kernel chunks)
If you transit the same application twice with the data, and the
chunk in the middle is IPSEC, and the chunk on the end is ALTQ,
then the arrow ...> can represent you peeking at the QOS information
in the unencrypted data, tunneling it so that it can be applied to
the encrypted data, before being haded to the chunk on the right
(ALTQ).
You can get away with this because your application sees the packets
twice, and can connect the requested QOS with the one you yourself
request.
This is a pretty gross hack, but it would probably let you string
the pieces you want together, using the tunneling info elsewhere
in this thread... good luck.
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
