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.
On Wed, 1 Nov 2000, Gregory Maxwell wrote:> 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?[..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) --->--->--->--->--[>--\ /-->]--->--->---> LOCAL NET [ SQUID ] OUTSIDE (yahoo) ---<---<---<---<--[<--/ \--<]---<---<---< (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. "So many links, so little time!"
On Wed, Nov 01, 2000 at 01:24:09PM -0300, Aldrin Martoq A. wrote:> 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 no, you probably won''t be talking bgp to your ''magic routers'', so you really don''t need to know gated.> 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.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
On Wed, 1 Nov 2000, bert hubert wrote:> On Wed, Nov 01, 2000 at 01:24:09PM -0300, Aldrin Martoq A. wrote: > > > 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. > > 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.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: http://xenu.xtdnet.nl/ | /__\ / | 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, arthurvl@sci.kun.nl------------------------+
Arthur van Leeuwen wrote:> On Wed, 1 Nov 2000, bert hubert wrote: > > > On Wed, Nov 01, 2000 at 01:24:09PM -0300, Aldrin Martoq A. wrote: > > > > > 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. > > > > 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. > > 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... ;) >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