All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul Wisen" <paul@busnet.se>
To: lartc@vger.kernel.org
Subject: SV: [LARTC] I know there must be a way ...
Date: Tue, 11 Dec 2001 23:19:09 +0000	[thread overview]
Message-ID: <marc-lartc-100811264713159@msgid-missing> (raw)

Got to ask..   (this is kind of cool btw) ..

What machine will he need to shape traffic at those speeds ?

Our ISP is probably interested.. We need to shape traffic at 155Mbit/s
speeds to do it though.. And, I mentioned that they probably should consider
to use a linuxbox to prioritize cusomer like us in favour of those private
customers on their fibre network... Or atleast do fair quing..

/ P

> -----Ursprungligt meddelande-----
> Fran: lartc-admin@mailman.ds9a.nl
> [mailto:lartc-admin@mailman.ds9a.nl]For bert hubert
> Skickat: den 12 december 2001 00:01
> Till: lartc@mailman.ds9a.nl
> Amne: Re: [LARTC] I know there must be a way ...
>
>
> On Tue, Dec 11, 2001 at 02:10:12PM -0800, George Bonser wrote:
>
> > Two providers. A primary I will call provider-A and a backup that I will
> > call provider-B. I collect full routes from both by BGP. My aggregate
> > traffic output varies from about 130MB in the middle of the night up to
> > about 300MB during the day ... a little lower on the weekends.
> Provider-B
> > is more expensive and has a 50MB minimum. I have fiddled with my BGP so
> > that I end up sending about 45-50MB of traffic to provider-B during my
> > peak time of the day.  What I would like to do is pretty much nail
> > provider-B to 50MB at all times using a Linux box in the traffic path.
>
> So you send 300mbit/s? Wow.
>
> > A bit more detail on what I am trying to do:
> >
> > A packet arriving from inside my network has 4 possible dispositions.
> >
> > 1. There is a route to the destination from both providers
> (most likely).
> > 2. There is a route only from Provider-A.
> > 3. There is a route only from Provider-B.
> > 4. There is no route from either provider.
> >
> > I can make zebra put routes into realms. I can then check
> arriving packets
> > to see if a realm has a route to the destination. Packets in
> disposition 2
> > must go to provider-A, packets in disposition 3 must go to provider-B.
> > Packets in disposition 1 are what I call "the pool" and may go
> to either A
> > or B to get to their distination.
>
> I get this.
>
> > What I want to do is create three streams ... A, B, and Pool. I need to
> > mark A so that it gets routed to provider-A (with FWMARK or some other
> > means ... say TOS), mark stream B so that it is nailed to
> provider B, BUT
> > when stream B is below 50MB, I want to pull in packets from the pool to
> > bring it up to 50. I do NOT want to rate-limit at 50 because if
> I loose my
> > link to provider-A or they have a peering issue, more than 50MB
> might need
> > to go to B, I just want to stop pulling traffic from the pool at that
> > point.  Any traffic in the pool remaining after B has pulled
> what it wants
> > would be marked for provider-A.
>
> Hmm. Hmmm. I think this can be done!
>
> You should attach an ingress shaper to all interfaces that
> receive traffic.
> I hope this is only one, or you will be in trouble. To attach an ingress
> shaper to multiple interfaces, you need it loaded as a module, btw,
> otherwise Bad Things will happen.
>
> Now, you must use a policing filter that will tag all traffic below
> 50mbit/s. Later on, you will use this tag to route with. All traffic above
> gets no tag, or another tag.
>
> The policing filter isn't the hard part, see the 'synflood' section in the
> HOWTO. The hard part is placing the mark. I think DSMARK does
> what you want.
> Later on, you must find a way to route based on the tc_index, as set by
> DSMARK. Perhaps by matching on it in iptables FORWARD and
> replacing it with
> an fwmark.
>
> I'm not sure. But I think the answer lies in DSMARK. Otherwise I
> can whip up
> a tc filter that does fwmark directly. Let me know.
>
> [ Ok, I reread what you want and it's a bit different, but these are the
>   tools available. You may need to create lots and lots of rules
> because you
>   need to be able to tell at ingress time where a packet is going to be
>   sent.  Tc filters can be hashed & are then lighting fast. ]
>
> If you get this working you can give a talk about it on whatever routing
> conference you choose, btw.
>
> Regards,
>
> bert
>
> --
> http://www.PowerDNS.com          Versatile DNS Software & Services
> Trilab                                 The Technology People
> Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
> 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/
>


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/

             reply	other threads:[~2001-12-11 23:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-11 23:19 Paul Wisen [this message]
2001-12-11 23:26 ` SV: [LARTC] I know there must be a way bert hubert

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=marc-lartc-100811264713159@msgid-missing \
    --to=paul@busnet.se \
    --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.