From: Grant Taylor <gtaylor@tnetconsulting.net>
To: lartc@vger.kernel.org
Subject: Re: tc question about ingress bandwidth splitting
Date: Fri, 03 Apr 2020 22:44:41 +0000 [thread overview]
Message-ID: <25c218d8-e045-fbe2-9bd9-31a3aef76423@tnetconsulting.net> (raw)
In-Reply-To: <74CFEE65-9CE8-4CF7-9706-2E2E67B24E08@redfish-solutions.com>
[-- Attachment #1: Type: text/plain, Size: 1295 bytes --]
On 4/1/20 3:48 AM, Marco Gaiarin wrote:
> Mandi! Grant Taylor
> In chel di` si favelave...
>
>
> Beh, something similar to what i do now for IFB:
>
> tc filter add dev eth1 parent ffff: protocol ip prio 50 \
> u32 match ip src 0.0.0.0/0 \
> flowid :1 \
> action mirred egress redirect dev ifb0
ACK
Thank you.
> AH! Sure, i meant 'bridge', not bond, sorry...
;-)
> I suppose, throw away 'ifb' and use veth in place. ;-)
If it makes sense for the need at hand.
> With 'tc' command above, i 'pipe' ingress to ifb; surely i can create
> a 'route' between phisical and veth interfaces, but clearly i have
> to manage a bit of routing and so on...
I'd expect to.
> Can you provide me some examples? Thanks.
Sure?
Add a veth interface (pair), bring the local one up, add an IP & subnet
to it, enable forwarding. Then on your remote system, add a route to
the new veth subnet via the eth0 IP.
The uncertainty above is that I doubt that this is what you're asking.
Please provide a hypothetical topology and I'll describe how it could be
implemented with network namespaces and veth pairs. (I don't know if
you are asking for an ifb alternative or something else.)
--
Grant. . . .
unix || die
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]
next prev parent reply other threads:[~2020-04-03 22:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-22 21:56 tc question about ingress bandwidth splitting Philip Prindeville
2020-03-22 22:59 ` Grant Taylor
2020-03-24 6:51 ` Philip Prindeville
2020-03-24 9:21 ` Marco Gaiarin
2020-03-24 17:57 ` Grant Taylor
2020-03-24 18:17 ` Grant Taylor
2020-03-26 3:44 ` Philip Prindeville
2020-03-26 3:53 ` Fwd: " Philip Prindeville
2020-03-26 12:50 ` Toke Høiland-Jørgensen
2020-03-26 4:03 ` Grant Taylor
2020-04-01 9:48 ` Marco Gaiarin
2020-04-03 22:44 ` Grant Taylor [this message]
2020-04-06 9:13 ` Marco Gaiarin
2020-04-13 1:11 ` Grant Taylor
2020-04-17 9:58 ` Marco Gaiarin
-- strict thread matches above, loose matches on Subject: below --
2020-03-22 18:20 Philip Prindeville
2020-03-23 6:47 ` Gáspár Lajos
2020-03-23 9:36 ` Marc SCHAEFER
2020-03-23 18:15 ` Philip Prindeville
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=25c218d8-e045-fbe2-9bd9-31a3aef76423@tnetconsulting.net \
--to=gtaylor@tnetconsulting.net \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.