Re: [LARTC] Routing NDAS ?
On 6/22/2007 5:22 PM, Andrew Lyon wrote: Are you saying that there is something wrong with proxy arp? So far it works fine for us, we have 5 segments and approx 150 nodes. Is there something wrong with driving a stake in to the ground with a rock verses a sledge hammer, no. I personally see no reason to ever use proxy arp when you can bridge. I also see much finer grained control over bridging than I do of proxy arp. Not to mention that with bridging, devices see the real MAC address verses the MAC of the device doing the proxy arp. That being said, proxy arp has been around for more decades than bridging has. I'm sure that there are situations where proxy arp is the better situation. However personally I would have to have a situation where bridging would not work and proxy arp would for me to use proxy arp over bridging. I guess some of this could be attributed to the fact that I have come in to networking with in the last 10 years and to me proxy arp is the old holdover about like NetBEUI is for some networks. (That is not to say that proxy arp has as many problems as NetBEUI does or vice versa.) Ndas devices don't work with proxy arp, bridge would, but at the moment we are a 24/7 operation and making the necessary config changes for bridge would be disruptive. Do you have another system that you can put in to production that would connect to both broadcast domains and have it bridge just NDAS traffic and let your existing routers do what they are doing? I can understand and appreciate the inability (technical / political / chronological) to be able to replace work on production systems. That does not mean that you can not accomplish what is needed another way. I will probably end up doing it, but I would like to know if there is any alternative.. Will adding a system just to bridge NDAS traffic work? Grant. . . . ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
RE: [LARTC] Routing NDAS ?
> >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >On Behalf Of Grant Taylor >Sent: 22 June 2007 22:45 >To: Mail List - Linux Advanced Routing and Traffic Control >Subject: Re: [LARTC] Routing NDAS ? > >On 06/22/07 16:31, Andrew Lyon wrote: >> the two segments are linked by a linux box that is doing routing and >> proxy arp, > >Please bridge and do not use Proxy ARP. Or if you really want to use >Proxy ARP make sure that you are only Proxy ARPing for the MAC addresses >of the NDAS device(s) and the client(s) that need to connect to it. Are you saying that there is something wrong with proxy arp? So far it works fine for us, we have 5 segments and approx 150 nodes. Ndas devices don't work with proxy arp, bridge would, but at the moment we are a 24/7 operation and making the necessary config changes for bridge would be disruptive. I will probably end up doing it, but I would like to know if there is any alternative.. Andy >> can anybody suggest a way that I could access the ndas devices, >Set up a bridging router (a.k.a. brouter) to bridge all layer 2 traffic >except for IP (and a few other select protocols) traffic. You may only >want to bridge traffic that is from the NDAS and or its client(s) and >route the rest (DROP in the BROUTING chain of the broute table). Grant. . . . ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc Registered Office: J.O. Sims Ltd, Pudding Lane, Pinchbeck, Spalding, Lincs. PE11 3TJ Company reg No: 2084187 Vat reg No: GB 437 4621 47 Tel: +44 (0) 1775 842100 Fax: +44 (0) 1775 842101 Web: www.josims.com Email:[EMAIL PROTECTED] The information contained in this e-mail is confidential and is intended for the addressee only. The contents of this e-mail must not be disclosed or copied without the sender's consent. If you are not the intended recipient of the message, please notify the sender immediately, and delete the message. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the company. No commitment may be inferred from the contents unless explicitly stated. The company does not take any responsibility for the personal views of the author. This message has been scanned for viruses before sending, but the company does not accept any responsibility for infection and recommends that you scan any attachments.JOSEDV001TAG ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Routing NDAS ?
On 06/22/07 16:31, Andrew Lyon wrote: the two segments are linked by a linux box that is doing routing and proxy arp, Please bridge and do not use Proxy ARP. Or if you really want to use Proxy ARP make sure that you are only Proxy ARPing for the MAC addresses of the NDAS device(s) and the client(s) that need to connect to it. can anybody suggest a way that I could access the ndas devices, Set up a bridging router (a.k.a. brouter) to bridge all layer 2 traffic except for IP (and a few other select protocols) traffic. You may only want to bridge traffic that is from the NDAS and or its client(s) and route the rest (DROP in the BROUTING chain of the broute table). Grant. . . . ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] Routing NDAS ?
Hi, I believe ndas devices (http://www.ximeta.com/web/technology/) use raw Ethernet frames, as they require no tcp/ip configuration, the client finds and authenticates with a code that is different for each device sold, like a network mac address. My pc is on a different segment to the ndas devices that we have, the two segments are linked by a linux box that is doing routing and proxy arp, can anybody suggest a way that I could access the ndas devices, I can connect to a share on a server that is connected to one of the devices, but that isn't very efficient :( Andy */ Ignore: JOSEDV001TAG /* ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Redundant internet connections. !!!SOLVED!!!
On 06/22/07 13:57, Grant Taylor wrote: I'm now going to test where the two routes are different MAC addresses to see if the traffic does indeed start using the proper rout again. Ok, I have done it and it is working. The short answer is all you need to have backup routes is to enter them in reverse order. You do not need to do any special kernel options, patch the kernel or any thing else, or any special ip rules. All you need to do is to enter the routes in the reverse of the order that you want them to be used. For example, if I have two different internet connections, each with their own default gateway. Obviously the two default gateways have to not be on the same subnet. GW1: A.B.C.D GW2: Z.Y.X.W GW3: K.L.M.N route add default gw K.L.M.N route add default gw Z.Y.X.W route add default gw A.B.C.D Note: All the above routes are the same metric (default of 0). I do not know why you have to add the routes in reverse. I have just noticed that route adds the routes as the highest priority to the routing table. Filled from the top, not the bottom type thing. So, conversely add them in the reverse order. In my current test environment I have two identical VMWare virtual machines (literal copy from one to the other) that I have modified the configuration and tested. I'll try to depict it below: ( ISP 1 ) --- ... --- ( ISP 1) --- ( Internet ) () | (DMZ) --- ( Router ) ( Peering Link) () | ( ISP 2 ) --- ... --- ( ISP 2) --- ( Internet ) In this scenario, the DMZ IP address space is from ISP 1. ISP 1 has a route to the DMZ via the ISP 1 IP address on my local Linux router. ISP 1 has a secondary route to the DMZ via the IP address on ISP 2s router over the peering link. ISP 2 has a route to the DMZ via the ISP 2 IP address on my local Linux router. The link between my local Linux router and ISP 1 is a high speed wireless link. The link between my local Linux router and ISP 2 is a lower speed ADSL link. The ADSL link from ISP 2 is *ONLY* used for backup access in case my local Linux router is unable to communicate with ISP 1s router. Thus if for some reason traffic does come in to my ISP 2 IP address it is to go back out the ISP 1 link, thus asymmetric routing. I appreciate all the suggestions that everyone submitted while trying to help resolve this issue. In the end it turned out that everything that was needed is already in the stock / vanilla kernel.org kernel. All I had to do was be smart enough to use it. Some points to help others with this issue if they ever need it: - Equal Cost Multi Path (a.k.a. E.C.M.P.) routing is NOT needed. - NO ip rule(s) were needed to pull this off. - NO additional routing tables were needed to pull this off. - NO patches (i.e. Julian's Dead Gateway Detection patch) were needed to make this off. - NO special scripts were needed to monitor and / or modify the routing table(s). (Note: This is applicable to my scenario, see below.) With regards to the monitoring of routing tables, I did not need to do any thing special, i.e. no ping or arping was needed. I think this was because when my primary route went down I would start using the secondary route and the returning traffic would always try to use the primary and fail back to the secondary route. When the primary route did come back up the inbound traffic would come in the primary interface / route thus incrementing the counters in my kernel thus making the kernel aware that the primary route was indeed back up so it could switch back to it. Note: In my test, I was manually taking the interface down on one VM and subsequently bring it back up and restoring the route(s) across it. In my opinion, this interface fiddling on the upstream end is not automatic, but is out side of the scope of the client end failing back to a backup route. If I were trying to do this between two systems where the link in the middle (between intermediary switches) went down, I believe I would have to do some sort of heart beat across the link. In this case, I would probably use (read: try) arping first and then switch to something else if that did not work. Grant. . . . ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Redundant internet connections.
On 06/21/07 17:35, Grant Taylor wrote: The problem with this method is that I have yet to get it to start re-using the primary route when it becomes available again. After doing some more testing and investigation, I think I know why the system appears to not be using the primary route. My test / lab setup consists of a Linux router with two subnets bound to one interface (eth0 and eth0:1) and my (VMWare) test Linux system with two ethernet interfaces bridged the the local LAN with one subnet on each interface. I have two (as far as Linux is concerned) physical interfaces so that I can have TX / RX counters for each interface to see which way the traffic is going out. This worked fine to have the system fall from the primary down to the secondary route when the primary route went away. However I never saw the traffic from the test Linux system back to the interface for the primary route. After doing some investigation I think this is because the same MAC address is used for both the primary and secondary routes, seeing as how both addresses are on the same physical interface on my Linux router. So, to test this, I took down the primary route, let the test Linux box fall back to the backup route, which it did. Then I brought the primary route back on line and waited. As expected the traffic did not start using the primary route, presumably because of MAC addresses for routes being cached with an association to a device. So, while the system was pinging out to the world with the primary route brought back up, I cleared entries from the local test Linux boxes ARP cache and all of the sudden, traffic started going out the correct interface. So, now I think that the method of having two equal cost (metric) routes on the box will work. I'm now going to test where the two routes are different MAC addresses to see if the traffic does indeed start using the proper rout again (Seeing as how there should not be any confusion with MAC addresses.) Grant. . . . ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] ATM [Cell Tax]
On Wednesday 20 June 2007 21:04, Nate Fuhriman wrote: > I have read the thread at > http://mailman.ds9a.nl/pipermail/lartc/2006q1/018287.html > and still don't know how to fix this problem. It appears alot of work > has gone into it but the HOWTO is so out of date it doesn't even begin > to addresses this method. > > So here are my questions > 1. what is the current state of these patches? are they in a specific > version? do i have to patch myself? > 2. how do i actually use this once patched in? an example script would > work great! > 3. is there a table for us mere mortals that describes how to figure > out which type of adsl/atm i'm using so i can set the appropriate > overhead? 4. Does someone know if there's a plan for the inclusion of these patches on iproute and the kernel? Thanks Gustavo > > thanks for all the great work on QOS! > nate > ___ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Angulo Sólido - Tecnologias de Informação http://angulosolido.pt ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] RE: PQ questions
Hi Christian, Good morning, and thank you for proving me correct about how professional and responsive people on this list are (sincerely). Brief comments in-line: > -Original Message- > From: Christian Benvenuti [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 21, 2007 4:23 PM > To: Tim Enos > Cc: [EMAIL PROTECTED]; lartc@mailman.ds9a.nl > Subject: Re: PQ questions > > Hi Tim, Andy, > > On Wed, 2007-06-20 at 19:07 -0400, Tim Enos wrote: > > It's PQ that is required. Here is what I have for config so far: > > > > tc qdisc add dev eth0 root handle 1: prio bands 4 priomap 0 1 2 3 > > Is "priomap 0 1 2 3" what you want/need or just a random mapping? > (this is the default mapping that is used when none of the filters > matches) > > > tc filter add dev eth0 parent 1:0 prio 1 protocol ip u32 match ip tos > 0xb8 > > 0xff flowid 1:1 > > > > tc filter add dev eth0 parent 1:0 prio 2 protocol ip u32 match ip tos > 0x50 > > 0xff flowid 1:2 > > > > tc filter add dev eth0 parent 1:0 prio 3 protocol ip u32 match ip tos > 0x28 > > 0xff flowid 1:3 > > > > tc filter add dev eth0 parent 1:0 prio 4 protocol ip u32 match ip tos > 0x00 > > 0xff flowid 1:4 > > > > > > tc qdisc add dev eth0 parent 1:1 handle 10: pfifo limit 2 > > > > tc qdisc add dev eth0 parent 1:2 handle 11: pfifo limit 2 > > > > tc qdisc add dev eth0 parent 1:3 handle 12: pfifo limit 2 > > > > tc qdisc add dev eth0 parent 1:4 handle 13: pfifo limit 2 > > > > __ > > > > The above config works fine. The last four qdisc lines (handles 10: - > 13: > > inclusive) also work as prio if you leave out the 'limit' part of > course. > > What do you mean? I mean that when saying something like: "qdisc add dev eth0 parent 1:1 handle 10: prio limit 2" you will get the following error (at least I do): " What is "limit"? Usage: ... prio bands NUMBER priomap P1 P2..." Changing the line like so works (and no error messages are generated): "qdisc add dev eth0 parent 1:1 handle 10: prio" > > > The remaining part is to set children for the last four qdiscs (one for > > each). Said children qdiscs would have all the same attributes (as the > > parents (limit is something I'd change; the '2' is just an example). Is > this > > possible? > > Do you mean something like this? > > tc qdisc add dev eth0 parent 10: handle 100: prio ... > tc qdisc add dev eth0 parent 11: handle 110: prio ... > tc qdisc add dev eth0 parent 12: handle 120: prio ... > tc qdisc add dev eth0 parent 13: handle 130: prio ... Yes. > > Why would you need to put a pfifo qdisc between the two prio qdisc? > Wouldn't it be better to have > > prio -> prio > > OR > > prio -> prio -> pfifo > > instead of > > prio -> pfifo -> prio ? > > What criteria are you going to use to assign the right priority to > the packets in the nested (i.e., 2nd level) prio qdisc? The idea is that within each of the four priority classes/queues there would be two queues: one of some very small length (say 2) and another of some larger length (whatever the default is). So the thinking is that the traffic (having been marked by the application say) hits the top-level queue. If the traffic is marked EF, it will go into the highest priority queue. Once in that queue, it will hit the first pfifo (which in this model is 2 packets long). It will then hit the second pfifo queue before heading out onto the wire. The ultimate concern is to know how many packets are in each of the priority queues at any given time. > > Regards > /Christian > [ http://benve.info ] > > > > > > -Original Message- > > > From: Andy Furniss [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, June 19, 2007 6:17 PM > > > To: Tim Enos > > > Cc: 'Christian Benvenuti'; lartc@mailman.ds9a.nl > > > Subject: Re: [LARTC] Re: PQ questions > > > > > > Tim Enos wrote: > > > > Cool, > > > > > > > > Thanks Christian! I'm wishing that all of those same params showed > up in > > > the > > > > output without having to run anything. No problem. Should it matter > that > > > I'm > > > > using an emulated interface? > > > > > > Quite possibly - using prio on real devices still can appear not to > work > > > until you have filled up any buffer the driver uses. > > > > > > On my 100meg eth it would take 5/6 unscaled tcp connections to fill > > > enough for prio to do anything. > > > > > > You can use prio as a child of hfsc/htb so that they set the rate. It > > > may be nicer to use htb's own prio though, if you need a slow rate and > > > care about latency. > > > > > > Andy. ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Redundant internet connections.
On 06/22/07 09:57, Gustavo Homem wrote: I've done this, but I think it's unreliable for professional use. The USB modems are non-standard so if one burns you can't exchange it for a different one without feasible but time consuming tweaking (tried more then one USB devices...). Even for Ethernet briding devices I only use models which are delivered by ISPs (rather than retail shop devices), to garantee they were tested for stability: POTS: http://www.huawei.com/products/terminal/products/view.do?id=87 ISDN: http://www.acbs-dsl-store.com/contenu/Articles/Article.asp?PdtNum=DSLGP628LP These models run forever in bridged mode. The second one accepts multiple PPPoE clients on different ports. That's expectable since using PPPoA instead of PPPoEoA, reduces the overhead. But I don't know a standard PPPoA setup. But if we want QoS working, we can't use the full line capability anyway. Even if that happens, it would hardly compensate the risk of lower reliability. All very valid points and things to consider. However for a home environment / non critical environment, it provides a lot of potential. Grant. . . . ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Redundant internet connections.
On Friday 22 June 2007 15:22, Grant Taylor wrote: > (Off thread topic.) > > On 06/22/07 06:54, Gustavo Homem wrote: > > This is absolutetly the way to do it with ADSL. > > I could not agree more. > > > Using a modem in bridged mode minimizes the responsability of the > > modem/router which is a potentially unstable device. Let the stable > > Linux box do the work (routing+nat) and get the public IP. And > > firewall the Linux box itself with iptables. This is the most > > flexible and stable way to go. > > *nod* About the only thing that I'm looking at doing differently at my > house is to use the Thompson USB SpeedTouch (330) USB ADSL modem to put > the ATM stack on the Linux box its self. I've done this, but I think it's unreliable for professional use. The USB modems are non-standard so if one burns you can't exchange it for a different one without feasible but time consuming tweaking (tried more then one USB devices...). Even for Ethernet briding devices I only use models which are delivered by ISPs (rather than retail shop devices), to garantee they were tested for stability: POTS: http://www.huawei.com/products/terminal/products/view.do?id=87 ISDN: http://www.acbs-dsl-store.com/contenu/Articles/Article.asp?PdtNum=DSLGP628LP These models run forever in bridged mode. The second one accepts multiple PPPoE clients on different ports. > This way the Linux kernel will > handle the bridging and buffering verses an external device that has > arbitrary pauses waiting for buffers to fill prior to transmitting data. > > My preliminary tests with the ATM stack on Linux show a speed increase > over the external bridging modem too. :) My tests show that Linux / That's expectable since using PPPoA instead of PPPoEoA, reduces the overhead. But I don't know a standard PPPoA setup. But if we want QoS working, we can't use the full line capability anyway. > Windows think the raw ATM with bridging circuit will get close to 1.6 > Mbps while the bridged devices get closer to 1.5 Mbps. I also see a > lower latency between the device connected to the DSL and the upstream > gateway by a factor of 3 - 5 ms. Even if that happens, it would hardly compensate the risk of lower reliability. Cheers Gustavo -- Angulo Sólido - Tecnologias de Informação http://angulosolido.pt ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Redundant internet connections.
(Off thread topic.) On 06/22/07 06:54, Gustavo Homem wrote: This is absolutetly the way to do it with ADSL. I could not agree more. Using a modem in bridged mode minimizes the responsability of the modem/router which is a potentially unstable device. Let the stable Linux box do the work (routing+nat) and get the public IP. And firewall the Linux box itself with iptables. This is the most flexible and stable way to go. *nod* About the only thing that I'm looking at doing differently at my house is to use the Thompson USB SpeedTouch (330) USB ADSL modem to put the ATM stack on the Linux box its self. This way the Linux kernel will handle the bridging and buffering verses an external device that has arbitrary pauses waiting for buffers to fill prior to transmitting data. My preliminary tests with the ATM stack on Linux show a speed increase over the external bridging modem too. :) My tests show that Linux / Windows think the raw ATM with bridging circuit will get close to 1.6 Mbps while the bridged devices get closer to 1.5 Mbps. I also see a lower latency between the device connected to the DSL and the upstream gateway by a factor of 3 - 5 ms. Grant. . . . ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] Redundant internet connections.
On Thursday 21 June 2007 18:02, Grant Taylor wrote: > On 06/21/07 11:47, Peter Rabbitson wrote: > > You are misunderstanding how ICMP works. The modems themselves are hops, > > and the thing they connect to is another hop. Just look at the first > > several entries of a traceroute to any destination, and you will see > > what I mean. If you still do not believe me - pull the ISP side cable > > from the modem, while still having your router connected to it, and try > > to do a ping to somewhere. Look at the source of the dest. unreachable > > message - it will come from the modem, not from the linux box. > > Um, if you are using bridging modems (like I am) you are incorrect. This is absolutetly the way to do it with ADSL. Using a modem in bridged mode minimizes the responsability of the modem/router which is a potentially unstable device. Let the stable Linux box do the work (routing+nat) and get the public IP. And firewall the Linux box itself with iptables. This is the most flexible and stable way to go. Cheers Gustavo -- Angulo Sólido - Tecnologias de Informação http://angulosolido.pt ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
