[LARTC] Queueing and BGP

[LARTC] Queueing and BGP

[Gregory]

<PRE>After seeing that post about directing traffic to various upstream links
based, basically, on the next-hop from an ISP's router I was wondering:

Is it possible to queue packets via realm?

As I seem to recall, it should be possible to configure GATED as an import
only BGP peer with your provider, then create a filter which causes GATED to
export all the prefixes which do not pass through the ASN on the
'international' side of your provider. You would make sure all these
prefixes are tagged with a specific realm number.

If it's possible to queue via realm (and my assumptions about GATED are not
incorrect), then this would make a more robust solution then figuring out
what prefixes are on the national network and creating rules for each one of
them.



</PRE>

[LARTC] Queueing and BGP

[Aldrin]

<PRE>On Wed, 1 Nov 2000, Gregory Maxwell wrote:
&gt;<i> After seeing that post about directing traffic to various upstream links
</I>&gt;<i> based, basically, on the next-hop from an ISP's router I was wondering:
</I>&gt;<i> Is it possible to queue packets via realm?
</I>[..gated..]

According to the LAR HOWTO (chapter 11.3); yes, it is possible to queue
via realm numbers.

Now, I'm a newbie (1.5 weeks ago just downloaded the LAR HOWTO and don't
understand it 100% right now) and found I have to learn BGP, gated, etc
;-)

Well, my question is: How can I control the BandWidth if you can only
control what you send on the wire? Remember that 99.99% of the traffic is
*download* of web pages, and there is a transparent proxy (with around
20%-50% hit rate on peak hours).
                             ____________
          www.yahoo.com (A) [            ] (B)
          ---&gt;---&gt;---&gt;---&gt;--[&gt;--\    /--&gt;]---&gt;---&gt;---&gt;
 LOCAL NET                  [   SQUID    ]                 OUTSIDE (yahoo)
          ---&lt;---&lt;---&lt;---&lt;--[&lt;--/    \--&lt;]---&lt;---&lt;---&lt;
                        (D) [____________] (C)

Whenever a packet from the local networks try to goes outside (A), it
really never goes outside because it is redirected to SQUID. Then SQUID
send the request packet (B) (which is a diferent packet) and it receives
the packet (C). The packet (C) vanish in SQUID, but it creates a new
packet (D) in response, which is not the same packet as (C).

So, It doesn't make sense to mark packet (C) because it will never go to
the local network and I cannot control that bandwidth, because I just
receive it. And also It doesn't make sense to mark packet (D) because
SQUID will eat all the bandwidth with packets (B) and (C) anyway.

Tell me I'm wrong.

Aldrin.
&quot;So many links, so little time!&quot;



</PRE>

[LARTC] Queueing and BGP

[bert]

<PRE>On Wed, Nov 01, 2000 at 01:24:09PM -0300, Aldrin Martoq A. wrote:

&gt;<i> Now, I'm a newbie (1.5 weeks ago just downloaded the LAR HOWTO and don't
</I>&gt;<i> understand it 100% right now) and found I have to learn BGP, gated, etc
</I>&gt;<i> ;-)
</I>
Well no, you probably won't be talking bgp to your 'magic routers', so you
really don't need to know gated.

&gt;<i> So, It doesn't make sense to mark packet (C) because it will never go to
</I>&gt;<i> the local network and I cannot control that bandwidth, because I just
</I>&gt;<i> receive it. And also It doesn't make sense to mark packet (D) because
</I>&gt;<i> SQUID will eat all the bandwidth with packets (B) and (C) anyway.
</I>
Because squids repackets your data, any shaping information is lost. Once
your data has left squid, there is no way to know anymore where it came
from. 

You can try to get the ingress policer working, which tries to do shaping on
the receiving interface (before squid). This should work, except that people
have been having trouble with the ingress policer.

Regards,

bert hubert

-- 
PowerDNS                     Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet


</PRE>

[LARTC] Queueing and BGP

[Arthur]

<PRE>On Wed, 1 Nov 2000, bert hubert wrote:

&gt;<i> On Wed, Nov 01, 2000 at 01:24:09PM -0300, Aldrin Martoq A. wrote:
</I>&gt;<i> 
</I>&gt;<i> &gt; So, It doesn't make sense to mark packet (C) because it will never go to
</I>&gt;<i> &gt; the local network and I cannot control that bandwidth, because I just
</I>&gt;<i> &gt; receive it. And also It doesn't make sense to mark packet (D) because
</I>&gt;<i> &gt; SQUID will eat all the bandwidth with packets (B) and (C) anyway.
</I>&gt;<i> 
</I>&gt;<i> Because squids repackets your data, any shaping information is lost. Once
</I>&gt;<i> your data has left squid, there is no way to know anymore where it came
</I>&gt;<i> from. 
</I>
&gt;<i> You can try to get the ingress policer working, which tries to do shaping on
</I>&gt;<i> the receiving interface (before squid). This should work, except that people
</I>&gt;<i> have been having trouble with the ingress policer.
</I>
Or, alternately, you might try to configure one squid per bandwith-partition, 
thereby getting back your shaping information. This does come at a cost, but
it is actually relatively easy to set up. You might need NAT to do it
though... ;)

Doei, Arthur. (Yaay, coding shaping information into IP addresses... ;))

-- 
  /\    /  |             Fight Scientology, See URL: <A HREF="http://xenu.xtdnet.nl/">http://xenu.xtdnet.nl/</A> |
 /__\  /   | Buttons. Lotsa buttons. I like buttons. [Big Dog]              |
/    \/__  | A friend is someone with whom you can dare to Be yourself.     |
 Just Be   +-Arthur van Leeuwen, <A HREF="mailto:arthurvl@sci.kun.nl------------------------+">arthurvl@sci.kun.nl------------------------+</A>



</PRE>

[LARTC] Queueing and BGP

[dancer]

<PRE>Arthur van Leeuwen wrote:

&gt;<i> On Wed, 1 Nov 2000, bert hubert wrote:
</I>&gt;<i>
</I>&gt;<i> &gt; On Wed, Nov 01, 2000 at 01:24:09PM -0300, Aldrin Martoq A. wrote:
</I>&gt;<i> &gt;
</I>&gt;<i> &gt; &gt; So, It doesn't make sense to mark packet (C) because it will never go to
</I>&gt;<i> &gt; &gt; the local network and I cannot control that bandwidth, because I just
</I>&gt;<i> &gt; &gt; receive it. And also It doesn't make sense to mark packet (D) because
</I>&gt;<i> &gt; &gt; SQUID will eat all the bandwidth with packets (B) and (C) anyway.
</I>&gt;<i> &gt;
</I>&gt;<i> &gt; Because squids repackets your data, any shaping information is lost. Once
</I>&gt;<i> &gt; your data has left squid, there is no way to know anymore where it came
</I>&gt;<i> &gt; from.
</I>&gt;<i>
</I>&gt;<i> &gt; You can try to get the ingress policer working, which tries to do shaping on
</I>&gt;<i> &gt; the receiving interface (before squid). This should work, except that people
</I>&gt;<i> &gt; have been having trouble with the ingress policer.
</I>&gt;<i>
</I>&gt;<i> Or, alternately, you might try to configure one squid per bandwith-partition,
</I>&gt;<i> thereby getting back your shaping information. This does come at a cost, but
</I>&gt;<i> it is actually relatively easy to set up. You might need NAT to do it
</I>&gt;<i> though... ;)
</I>&gt;<i>
</I>
Hrm. Throttling it on transmission on the internal network interface works for
me....squid doesn't get too far out of control because it won't read too far ahead
of the client. Unfortunately throttling at that point means that cache-hits get
throttled, since I can't think of a good way to deal with this (I'm marking and
queuing on egress into two bandwidth partitions [fast and slow]). Proxy/web
traffic falls into the 'slow' category...and like I said...squid only reads ahead
so far, thus winding up in synch with the client-read speed for any large
objects...it's the cache hits that bite....From the end-user perspective, a hit
looks like a miss...Ie: Same delivery rate.

D




</PRE>