All of lore.kernel.org
 help / color / mirror / Atom feed
From: bert hubert <ahu@ds9a.nl>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] I know there must be a way ...
Date: Tue, 11 Dec 2001 23:19:13 +0000	[thread overview]
Message-ID: <marc-lartc-100811285713671@msgid-missing> (raw)
In-Reply-To: <marc-lartc-100810869803719@msgid-missing>

On Tue, Dec 11, 2001 at 02:10:12PM -0800, George Bonser wrote:

> dug up enough parts to cobble something together to do what I need but I
> am befuddled. Here is a description of my problem:
> 
> 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.

Ok - I missed this. So we have this
                                                       A
                                                     /  
  [ your network ]  - [ linux machine ] - [ router ] 
                                                     \ 
                                                       B

The Linux machine also has a full view and knows where traffic will go. 

But the router does its own routing? 

> 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).

Should be so yes. Your router routes on AS path length however.

> 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.

Well, tricky! Even if the Linux box knows, it should communicate this to the
router. Perhaps you can do measurements in the FORWARD chain and reconfigure
your router based on those measurements?

The linux machine only knows at egress where traffic will go, by then it's
really too late to do anything about it, except possibly DSMARK stuff.

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/

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

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-11 22:10 [LARTC] I know there must be a way George Bonser
2001-12-11 23:00 ` bert hubert
2001-12-11 23:19 ` bert hubert [this message]
2001-12-12 20:10 ` George Bonser

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-100811285713671@msgid-missing \
    --to=ahu@ds9a.nl \
    --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.