Re: [LARTC] Combining ingress and egress ( IMQ+HTB)
The way I understand it is summed up in a quote from "LEAF Bering user's guide" --- In many cases like those of ISPs, the bandwidth allocation is for incoming and outgoing combined. Under such situations, in stock linux, a virtual device called IMQ has been created through which all traffic passes. Thus shaping on IMQ will enable shaping total traffic and not incoming and outgoing separately. --- On Wednesday June 25 2003 02:37 pm, Rajesh Srivastava wrote: > I am successfully running ingress (IMQ) and egress (HTB) shaping on a > bridge. > > Is there any way to combine and share the bandwidth between ingress and > egress? > > Example: > I have set up www service for egress at 128 KB and ingress at 256 KB. The > shaping on them works fine separately. However, I want to create a single > virtual pipe for www traffic and limit both ingress and egress combined to > 256 KB. > > Thanks. > > Rajesh > > > ___ > LARTC mailing list / [EMAIL PROTECTED] > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ -- Regards Joseph Watson ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Traffic shaping for upload & download
Hello, I have a question about two way traffic, and how to shape it? Lets say we want to limit a customer usage to 256kbit total. So on my firewall I add shaping rules to the client side nice with a ceiling of 256kbit. Now I also want to limit there upload, so I add the same to the other nice in the firewall. But if the customer uploads and downloads at the same time, they could use up 512kbit of my connection. How can one handle this problem. Is there a way to specify a max for all traphic and then alow barrowing between upload and download?? Or it this a limitation that I will have to live with? -- Regards Joseph Watson ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] What Queue should I use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I have a linuxbox that I want to use to limit connection speeds. This box is on a 100Mbit network, and this networks gateway to the internet is a T1. So I can not do fairness queueing here, but am not really worried about this because I think Frame Relay does a farely good job of this. What I want to do, is place a hard maximum data rate per client. I may have 100 clients with a max of 128 Kbit some day. All I am interested is placing the clients in a class based on IP, and limiting the maximum datarate. - -- Regards Joseph Watson -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9m4xIABydhMNsDgMRAqKMAJ4pJxP8mlglHnrMJSvUIwB0nnVY/wCggRlO rmKe3wqV1mQhDdbmVV1JOk0= =0rfH -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Simple question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 30 September 2002 01:07 am, Joseph Watson wrote: > Hello, > Sorry I have the wrong list here :) - -- Regards Joseph Watson -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9l92+ABydhMNsDgMRAp1vAJ9wUqtPWCqXGOqVN2hu+dJtX+oKFQCgkBub 7DK5G7KEIqa3EwkbZUeiIXc= =HiAH -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Simple question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I have a linuxbox running shorewall, and on the lan side nic I have multiple networks, and ip's from both assigned to the nic. One network is private, and the other is public ip's. I have a web server running on the firewall with multiple virtual hosts configured. I have the private ip on the lan tied to the default apache config, and the public ip on the lan tied to a vurtual configuration. Also the public ip on the wan is tied to another virtual host. I want all web traffic on the private network that is trying to go through the firewall to get forwarded to the firewall and be answered by the apache default config. All this config will do is redirects the request to my domain. So no matter where they try to go, they will end up at my page. The following will do the trick. ACCEPT lan:192.168.1.0/24fw:192.168.1.1:80 tcp http - all I think it is required to specify the 192.168.1.1 on the firewall so it is answered by the proper apache config. Am I right? The 192.168.1.1 is the main ip on the nic, and the public ip is a alias. Then came the question, will the following rule do the same thing? ACCEPT lan:192.168.1.0/24lan:192.168.1.1:80 tcp http - all Would this act any different? - -- Regards Joseph Watson -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9l9v5ABydhMNsDgMRAqX/AJ49x9j4fK4eVuwfQJMxA15YWKdHoACgzhKv mGExxcT5A/DK6prz2L1yBog= =z1pS -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
[LARTC] Mailing list problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Every time I post to this list, I recieve non-deliverable responces such as the follow: nonexist mail account : [EMAIL PROTECTED] [EMAIL PROTECTED] in Mon, 30 Sep 2002 12:46:12 +0800 Subject: Re: [LARTC] Rip problems user can't receive this mail now due to non exist mail account I did not send it to this account, I posted to the list. It seems that there is a bad subscriber on the list, but why do I get these notices. I was just wondering if this is normal for this list setup, or if it is something that could be fixed. - -- Regards Joseph Watson -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9l9kbABydhMNsDgMRAq+PAKDoj5wtStO4m0dMpXdg2DMyPMma6ACgrGnQ iyBmwt046LLr+yW93LUiiX4= =8f5a -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Rip problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 29 September 2002 02:50 pm, Ramin Alidousti wrote: > > I have added a static route to the portmaster until I can figure this > > out. > > Yes. For your setup static route is good enough and possibly the easiest. > But just as an exercise, I'd like to know what the problem is. > > Ramin Well, doesn't this just figure. I tried to recreate the problem and it no longer exists?? I removed the static routes from the portmaster and rebooted it. I then started routed on the linux box and it is 2 hours now and working perfectly! I have a hunch that I know what the problem was though. There was a problem with the pool on one portmaster, and it was spilling over into the 128/26 network. I corrected the problem and reset all ports so that everyone had to log back on, and nobody was assigned an address from the 128/26 network, but I did not reboot it. It must have been trying to keep possesion of the 128/26 network for its own use??? Thanks much. - -- Regards Joseph Watson -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9l9VzABydhMNsDgMRAik5AJ9kfUIQCZslxZ0BqyVQvoDJ8iKruACgrQ9B mBbmniv0KBPZR2csFkxEGqo= =fNmW -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Rip problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 28 September 2002 11:43 pm, Ramin Alidousti wrote: > Can you explain what exactly was working in the first few minutes? Did you > actually see a /26 route on the portmaster? There are a few timers in RIP. > The 30 sec you mentioned reminds me of the the update advertisement timer > and the 3 min interval is the holddown timer. What is the topology and > where does the remaining block (C - /26) reside? You said that you have a > class C. Is it a class C or a /24? iaw what is the natural class of your > netblock? Do you also run RIP between the portmaster and that other part? > This is important because if you do you'll end up having two different > routes to the same natural class of your netblock which is not what you > want. > > > I think I am going to try gated. > > A better choice is zebra if you're already familiar with cisco syntax. > Does your portmaster support OSPF? > > Ramin I will try to be as complete as possible :) I have a /24, ie xx.xx.xx.0 - xx.xx.xx.255 This is split into 4 subnets ie /26 The xx.xx.xx.0/26 subnet is used on the network that the portmaster is plugged into. I also have a second Portmaster on this network, and xx.xx.xx.63/26 is asigned to the modem pool split between the portmasters. The routing is taken care of by rip on the two portmasters. Now on the same xx.xx.xx.0/26 network, I have a linux box. Behind this Linux Box is where I have the xx.xx.xx.128/26 network. xx.xx.xx.192/26 is not being used now. ,---modems in the xx.xx.xx.64/26 ---, ,-'--. ,-'---. - ---T1--CSU/DSU--| portmaster |---xx.xx.xx.0/26---| portmaster2 | ``| `-` ,--. | Linux Box | `--` | xx.xx.xx.128/26 Now, I am monitoring the routing tables in the portmaster connected to the T1. Since it is the gateway this is what matters for incoming traffic. When I start routed on the linuxbox, after 30 seconds it broadcasts its info, and the portmaster updated its routes with a xx.xx.xx.128/26: I can then access clients on the xx.xx.xx.128/26 network behind the linux box. But after 3min's, routed start brodcasting the route to the 128/26 network with a metric of 16. And as expected, I can't access the 128/26 network anymore. Then it started broadcasting a route to the xx.xx.xx.0/24 network Where does it get this from?? What I can't figure out is why routed changes what it is broadcasting?? So it is something to do with routed on the linux box! I monitored all rip traffic with tcpdump (a previous post has this info) and nothing else is telling it to change the routing. The only other rip divices on the network are the portmasters, and they are taking care of the xx.xx.xx.64/26 network that the modems are on. Gated talks about routes from the local interface config timing out, and there is config options to prevent this. Maybe this is what I am seeing with routed?? I have added a static route to the portmaster until I can figure this out. Thanks for the help - -- Regards Joseph Watson -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9lozxABydhMNsDgMRAmJ7AKC2cS/bNkAbaJIQBojSTpnU1yRqsgCffk+D yCXIDHSYEUNPVm1qrkek4mg= =mzJ/ -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Rip problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 28 September 2002 03:39 pm, you wrote: > >Any Ideas? > > I've not been following closely, but could this be a RIPv1 vs RIPv2 thing ? > > (As I understand things, RIPv1 did not support CIDR, but RIPv2 does). Im not sure, but it worked for the first few minutes and then routed started changing the routing tables, and I don't know where this info was coming from??? I think I am going to try gated. - -- Regards Joseph Watson -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9lgcdABydhMNsDgMRAkvBAJ9YOpwPcYrY8rIYzXbcDEyYK/PVkgCg2xiG bnfpmXr42tUrqFNr8WAMdSI= =+cEd -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Rip problems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I have identified the source of the problem, but not the cause of it. Here is a output
from
tcpdump that shows the rip traffic from the routed process on the linuxbox. Again I
have
configured routed as follows:
EXPORT_GATEWAY="no"
SILENT="no"
and it gets its information from the network setup on the localmachine.
in the following output, all xx.xx.xx. represent the same class C address.
[root@dwwireless httpd]# tcpdump -ni eth0 udp port 520 and src host xx.xx.xx.52
tcpdump: listening on eth0
12:33:16.427345 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:33:21.658707 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(16) {xx.xx.xx.0}(16) (DF) <- restarted routed --
12:33:22.359761 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-req 24 (DF)
12:33:52.358588 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:
{xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:34:22.359529 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:
{xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:34:52.360541 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:
{xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:35:22.361625 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:
{xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:35:52.362543 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:
{xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:36:22.365285 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:
{xx.xx.xx.192}(16) {192.168.1.0}(1)[|rip] (DF)
12:36:52.364554 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:
{xx.xx.xx.192}(16) {192.168.1.0}(1)[|rip] (DF)
12:37:22.365592 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:37:52.366556 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:38:22.367531 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:38:52.368547 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:39:22.369516 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:39:52.370524 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:40:22.371571 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:40:52.372525 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:41:22.373521 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:41:52.374513 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:42:22.375511 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:42:28.221015 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(16) {xx.xx.xx.0}(16) (DF) < restarted routed ---
12:42:28.937439 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-req 24 (DF)
12:42:59.066864 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:
{xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:43:29.067806 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:
{xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:43:59.068802 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:
{xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:44:29.069811 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:
{xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:44:59.070798 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:
{xx.xx.xx.192}(1) {192.168.1.0}(1)[|rip] (DF)
12:45:29.073590 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:
{xx.xx.xx.192}(16) {192.168.1.0}(1)[|rip] (DF)
12:45:59.072795 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 3]:
{xx.xx.xx.192}(16) {192.168.1.0}(1)[|rip] (DF)
12:46:29.073861 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:46:59.074794 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:47:28.741356 xx.xx.xx.52.520 > xx.xx.xx.62.520: RIPv1-resp [items 13]:
{xx.xx.xx.65}(2) {xx.xx.xx.67}(2)[|rip] (DF)
12:47:29.075708 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
12:47:59.076795 xx.xx.xx.52.520 > xx.xx.xx.63.520: RIPv1-resp [items 2]:
{192.168.1.0}(1) {xx.xx.xx.0}(1) (DF)
As you can see, routed is expiring the route xx.xx.xx.192 network, and adding one to
the hole class C block.
This is obviously wrong, and I don't know why it is changing its routing information
in mid swing???
Any Ideas?
[LARTC] Rip problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I am running a portmaster for dialup customers. This portmaster has a T1 connected to it, and is the gateway to the internet. Behind it I have a class C network divided up into 4 subnets, netmask 255.255.255.192 or /26. One of the subnets is behind my linuxbox (the 192 network). The portmaster is running rip(1), so I installed routed on the linux box, and configured it to share its information. ie. EXPORT_GATEWAY="no" SILENT="no" When I start routed, the appropriate routes show up in the portmaster after about a 30 seconds, and all works good for about 2 1/2 minutes. Then the portmaster sets the Metric to 16 for the route to my subnet behind the firewall, and routing quits working. If I restart routed, we will repeat the process. If I stop routed during the 2 1/2 mins, it will immediately set the Met to 16. This tells me that they are communicating because when I shut routed down the metric is set to 16. But why does this happen exactly at 2 1/2 min?? I am quite confused? Any suggestions would be great. - -- Regards Joseph Watson -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9lesTABydhMNsDgMRAuZzAKCDKkKGviW6PYX4YxDyTfyzikNhHQCeLiSz +cONh6fjWlgOY4eirljT0CI= =vgXh -END PGP SIGNATURE- ___ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
