Neil Greatorex
2004-Sep-23 15:09 UTC
Prioritizing forwarded traffic over locally generated traffic
Hi, I'm a complete newbie at this traffic shaping / QoS stuff so please excuse me if this is a silly question. I've searched and searched on Google and I just end up confusing myself even more, so I thought I'd post my question to this list and see whether someone can help me! Basically, I am running a Linux box as a NAT router on my home network (machine name marvin). I want to use mldonkey on the router box for P2P downloads. What I wish to do, is to have any traffic that originates on the internal LAN take priority over traffic that is generated from mldonkey on marvin. I don't wish to restrict the maximum bandwidth for the P2P downloads on a permanent basis if I can help it - so that all the bandwidth is used all of the time. My plan was to use the PREROUTING and OUTPUT chains of the mangle table to mark the packets, and then use some form of qdisc/class structure that will prioritise one over the other. The aim of this is to have an upload that would normally take say 20 seconds from a machine on the LAN still take 20 seconds when mldonkey is uploading - so the NAT traffic will take all the bandwidth away from mldonkey. The closer to this aim I can get the better! To test implementations, I am using SFTP to upload a file from both a machine on my internal network (named slartibartfast), and marvin (the router machine) simultaneously. The perfect behaviour would be for the upload on slartibartfast to take 20 seconds, and the upload on marvin to take 40. I have tried various setups of qdiscs and classes, using various examples from all over the web (including the LARTC FAQ/cookbook) but I haven't been able to get anywhere near my aim. All of the attempts I've made have led to both uploads taking near enough 40 seconds, as they are both running at 50% of the available bandwidth. I would like it to give almost all the bandwidth to slartibartfast for the first 20 seconds, and then all the bandwidth to marvin for the remaining time. I would really appreciate it if someone could tell me whether: a) This setup is actually possible! b) If using the mangle table chains is correct for this c) If it is, the easiest/best/fastest way to implement it. Just some hints for the right direction would be fine! Many thanks in advance, Neil Greatorex
Jason Boxman
2004-Sep-23 15:34 UTC
Prioritizing forwarded traffic over locally generated traffic
On Thursday 23 September 2004 18:09, Neil Greatorex wrote: > Hi, > > I'm a complete newbie at this traffic shaping / QoS stuff so please excuse > me if this is a silly question. I've searched and searched on Google and I > just end up confusing myself even more, so I thought I'd post my question > to this list and see whether someone can help me! Sure. > Basically, I am running a Linux box as a NAT router on my home network > (machine name marvin). I want to use mldonkey on the router box for P2P > downloads. What I wish to do, is to have any traffic that originates on the > internal LAN take priority over traffic that is generated from mldonkey on > marvin. I don't wish to restrict the maximum bandwidth for the P2P > downloads on a permanent basis if I can help it - so that all the bandwidth > is used all of the time. So you'd like to classify p2p traffic from mldonkey (Overnet/Kad/eDonkey) such that it is granted a lower priority than other traffic? Not a problem. However, because those three protocols use random ports, you cannot classify 'edonkey' traffic based on port. You can use either ipp2p or L7-Filter to match these flows based on layer 7 pattern matching, though. > My plan was to use the PREROUTING and OUTPUT chains of the mangle table to > mark the packets, and then use some form of qdisc/class structure that will > prioritise one over the other. I believe you can use the POSTROUTING chain of the mangle table and nab all traffic. L7-Filter has a nice graphic[1] available. [1] http://l7-filter.sourceforge.net/PacketFlow.png > The aim of this is to have an upload that would normally take say 20 > seconds from a machine on the LAN still take 20 seconds when mldonkey is > uploading - so the NAT traffic will take all the bandwidth away from > mldonkey. The closer to this aim I can get the better! That makes sense, although the time interval is relative to the data size and protocol being used, so it isn't a useful measure for the rest of us. What's the link size? What's the file / data size? > To test implementations, I am using SFTP to upload a file from both a > machine on my internal network (named slartibartfast), and marvin (the > router machine) simultaneously. The perfect behaviour would be for the > upload on slartibartfast to take 20 seconds, and the upload on marvin to > take 40. Which implementations have you tried to use? I'd imagine Wondershaper? Others? > I have tried various setups of qdiscs and classes, using various examples > from all over the web (including the LARTC FAQ/cookbook) but I haven't been > able to get anywhere near my aim. All of the attempts I've made have led to > both uploads taking near enough 40 seconds, as they are both running at 50% > of the available bandwidth. I would like it to give almost all the > bandwidth to slartibartfast for the first 20 seconds, and then all the > bandwidth to marvin for the remaining time. The problem is likely that you cannot effectively match p2p flows that use the 'edonkey' protocols. (Actually, the latest L7-Filter pattern matches do not yet match eMule's new Kad network, so you'll still need to either disable support for that in mldonkey or deal with latency issues that arise.) > I would really appreciate it if someone could tell me whether: > a) This setup is actually possible! Absolutely! > b) If using the mangle table chains is correct for this I believe so. > c) If it is, the easiest/best/fastest way to implement it. Just some hints > for the right direction would be fine! You might explore my guide[2]. I have a setup quite similar to the one you wish to implement, except on my router does not generate any traffic. (I have mldonkey running on an internal machine instead.) [2] http://trekweb.com/~jasonb/articles/traffic_shaping/ > Many thanks in advance, > Neil Greatorex >
Sounds to me like he's trying to match via source IP.. which would catch everything just fine.. Niel, I do something very similar, its fairly simple.. you want to mark packets in your prerouting, then match against them in your qdiscs.. i use an htb.. my upload link can handle about 85 kilobytes / sec. I have several classes that match with various rates, the cieling for all of them is ~80 Then i have a class that matches the mark that i use for that specific IP. That mark goes into a class with a rate of 2 KB/s and a cieling of 75 that class gets 75 when nothing else is running, and 2 if other classes are filling it up. Hope this helps, Jason Jason Boxman wrote: >On Thursday 23 September 2004 18:09, Neil Greatorex wrote: > > >>Hi, >> >>I'm a complete newbie at this traffic shaping / QoS stuff so please excuse >>me if this is a silly question. I've searched and searched on Google and I >>just end up confusing myself even more, so I thought I'd post my question >>to this list and see whether someone can help me! >> >> > >Sure. > > > >>Basically, I am running a Linux box as a NAT router on my home network >>(machine name marvin). I want to use mldonkey on the router box for P2P >>downloads. What I wish to do, is to have any traffic that originates on the >>internal LAN take priority over traffic that is generated from mldonkey on >>marvin. I don't wish to restrict the maximum bandwidth for the P2P >>downloads on a permanent basis if I can help it - so that all the bandwidth >>is used all of the time. >> >> > >So you'd like to classify p2p traffic from mldonkey (Overnet/Kad/eDonkey) such >that it is granted a lower priority than other traffic? Not a problem. >However, because those three protocols use random ports, you cannot classify >'edonkey' traffic based on port. You can use either ipp2p or L7-Filter to >match these flows based on layer 7 pattern matching, though. > > > >>My plan was to use the PREROUTING and OUTPUT chains of the mangle table to >>mark the packets, and then use some form of qdisc/class structure that will >>prioritise one over the other. >> >> > >I believe you can use the POSTROUTING chain of the mangle table and nab all >traffic. L7-Filter has a nice graphic[1] available. > >[1] http://l7-filter.sourceforge.net/PacketFlow.png > > > >>The aim of this is to have an upload that would normally take say 20 >>seconds from a machine on the LAN still take 20 seconds when mldonkey is >>uploading - so the NAT traffic will take all the bandwidth away from >>mldonkey. The closer to this aim I can get the better! >> >> > >That makes sense, although the time interval is relative to the data size and >protocol being used, so it isn't a useful measure for the rest of us. What's >the link size? What's the file / data size? > > > >>To test implementations, I am using SFTP to upload a file from both a >>machine on my internal network (named slartibartfast), and marvin (the >>router machine) simultaneously. The perfect behaviour would be for the >>upload on slartibartfast to take 20 seconds, and the upload on marvin to >>take 40. >> >> > >Which implementations have you tried to use? I'd imagine Wondershaper? >Others? > > > >>I have tried various setups of qdiscs and classes, using various examples >>from all over the web (including the LARTC FAQ/cookbook) but I haven't been >>able to get anywhere near my aim. All of the attempts I've made have led to >>both uploads taking near enough 40 seconds, as they are both running at 50% >>of the available bandwidth. I would like it to give almost all the >>bandwidth to slartibartfast for the first 20 seconds, and then all the >>bandwidth to marvin for the remaining time. >> >> > >The problem is likely that you cannot effectively match p2p flows that use the >'edonkey' protocols. (Actually, the latest L7-Filter pattern matches do not >yet match eMule's new Kad network, so you'll still need to either disable >support for that in mldonkey or deal with latency issues that arise.) > > > >>I would really appreciate it if someone could tell me whether: >>a) This setup is actually possible! >> >> > >Absolutely! > > > >>b) If using the mangle table chains is correct for this >> >> > >I believe so. > > > >>c) If it is, the easiest/best/fastest way to implement it. Just some hints >>for the right direction would be fine! >> >> > >You might explore my guide[2]. I have a setup quite similar to the one you >wish to implement, except on my router does not generate any traffic. (I >have mldonkey running on an internal machine instead.) > >[2] http://trekweb.com/~jasonb/articles/traffic_shaping/ > > > >>Many thanks in advance, >>Neil Greatorex >> >> >> > >_______________________________________________ >LARTC mailing list / LARTC@mailman.ds9a.nl >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >
Neil Greatorex
2004-Sep-24 09:55 UTC
Prioritizing forwarded traffic over locally generated traffic
Many thanks to both of you for your replies. I have managed to get the setup working how I intended now - by using HTB classes/qdiscs. I had tried this approach before as one of many, however what I had failed to do was create the two classes I am filtering the traffic into as subclasses of a parent HTB class that was limited to the rate of the connection. Now it works as I intended! I'm now going to tackle the harder problem of doing it for downloading - I'm off to play with IMQ :-) Again, many thanks for your suggestions/advice! Cheers, Neil -- #include "sig.h" #define NAME "Neil Greatorex" #define E-MAIL "neil@fatboyfat.co.uk" http://www.spreadfirefox.com/?q=affiliates&id=7889&t=58 > -----Original Message----- > From: lartc-admin@mailman.ds9a.nl > [mailto:lartc-admin@mailman.ds9a.nl] On Behalf Of kraquen > Sent: 24 September 2004 6:36 AM > To: jasonb@edseek.com > Cc: lartc@mailman.ds9a.nl > Subject: Re: [LARTC] Prioritizing forwarded traffic over > locally generated traffic > > Sounds to me like he's trying to match via source IP.. which > would catch > everything just fine.. > > Niel, > I do something very similar, its fairly simple.. > > you want to mark packets in your prerouting, then match > against them in > your qdiscs.. > > i use an htb.. my upload link can handle about 85 kilobytes / sec. > > I have several classes that match with various rates, the cieling for > all of them is ~80 > > Then i have a class that matches the mark that i use for that > specific IP. > > That mark goes into a class with a rate of 2 KB/s and a cieling of 75 > > that class gets 75 when nothing else is running, and 2 if > other classes > are filling it up. > > Hope this helps, > Jason > Jason Boxman wrote: > > >On Thursday 23 September 2004 18:09, Neil Greatorex wrote: > > > > > >>Hi, > >> > >>I'm a complete newbie at this traffic shaping / QoS stuff > so please excuse > >>me if this is a silly question. I've searched and searched > on Google and I > >>just end up confusing myself even more, so I thought I'd > post my question > >>to this list and see whether someone can help me! > >> > >> > > > >Sure. > > > > > > > >>Basically, I am running a Linux box as a NAT router on my > home network > >>(machine name marvin). I want to use mldonkey on the router > box for P2P > >>downloads. What I wish to do, is to have any traffic that > originates on the > >>internal LAN take priority over traffic that is generated > from mldonkey on > >>marvin. I don't wish to restrict the maximum bandwidth for the P2P > >>downloads on a permanent basis if I can help it - so that > all the bandwidth > >>is used all of the time. > >> > >> > > > >So you'd like to classify p2p traffic from mldonkey > (Overnet/Kad/eDonkey) such > >that it is granted a lower priority than other traffic? Not > a problem. > >However, because those three protocols use random ports, you > cannot classify > >'edonkey' traffic based on port. You can use either ipp2p > or L7-Filter to > >match these flows based on layer 7 pattern matching, though. > > > > > > > >>My plan was to use the PREROUTING and OUTPUT chains of the > mangle table to > >>mark the packets, and then use some form of qdisc/class > structure that will > >>prioritise one over the other. > >> > >> > > > >I believe you can use the POSTROUTING chain of the mangle > table and nab all > >traffic. L7-Filter has a nice graphic[1] available. > > > >[1] http://l7-filter.sourceforge.net/PacketFlow.png > > > > > > > >>The aim of this is to have an upload that would normally take say 20 > >>seconds from a machine on the LAN still take 20 seconds > when mldonkey is > >>uploading - so the NAT traffic will take all the bandwidth away from > >>mldonkey. The closer to this aim I can get the better! > >> > >> > > > >That makes sense, although the time interval is relative to > the data size and > >protocol being used, so it isn't a useful measure for the > rest of us. What's > >the link size? What's the file / data size? > > > > > > > >>To test implementations, I am using SFTP to upload a file > from both a > >>machine on my internal network (named slartibartfast), and > marvin (the > >>router machine) simultaneously. The perfect behaviour would > be for the > >>upload on slartibartfast to take 20 seconds, and the upload > on marvin to > >>take 40. > >> > >> > > > >Which implementations have you tried to use? I'd imagine > Wondershaper? > >Others? > > > > > > > >>I have tried various setups of qdiscs and classes, using > various examples > >>from all over the web (including the LARTC FAQ/cookbook) > but I haven't been > >>able to get anywhere near my aim. All of the attempts I've > made have led to > >>both uploads taking near enough 40 seconds, as they are > both running at 50% > >>of the available bandwidth. I would like it to give almost all the > >>bandwidth to slartibartfast for the first 20 seconds, and > then all the > >>bandwidth to marvin for the remaining time. > >> > >> > > > >The problem is likely that you cannot effectively match p2p > flows that use the > >'edonkey' protocols. (Actually, the latest L7-Filter > pattern matches do not > >yet match eMule's new Kad network, so you'll still need to > either disable > >support for that in mldonkey or deal with latency issues that arise.) > > > > > > > >>I would really appreciate it if someone could tell me whether: > >>a) This setup is actually possible! > >> > >> > > > >Absolutely! > > > > > > > >>b) If using the mangle table chains is correct for this > >> > >> > > > >I believe so. > > > > > > > >>c) If it is, the easiest/best/fastest way to implement it. > Just some hints > >>for the right direction would be fine! > >> > >> > > > >You might explore my guide[2]. I have a setup quite similar > to the one you > >wish to implement, except on my router does not generate any > traffic. (I > >have mldonkey running on an internal machine instead.) > > > >[2] http://trekweb.com/~jasonb/articles/traffic_shaping/ > > > > > > > >>Many thanks in advance, > >>Neil Greatorex > >> > >> > >> > > > >_______________________________________________ > >LARTC mailing list / LARTC@mailman.ds9a.nl > >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: > http://lartc.org/ > > > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >
Jason Boxman
2004-Sep-24 10:07 UTC
Prioritizing forwarded traffic over locally generated traffic
On Friday 24 September 2004 12:55, Neil Greatorex wrote: > Many thanks to both of you for your replies. > > I have managed to get the setup working how I intended now - by using HTB > classes/qdiscs. I had tried this approach before as one of many, however > what I had failed to do was create the two classes I am filtering the > traffic into as subclasses of a parent HTB class that was limited to the > rate of the connection. Now it works as I intended! > > I'm now going to tackle the harder problem of doing it for downloading - > I'm off to play with IMQ :-) Indeed. Some people experience success setting up another egress qdisc on the router's internet NIC and shaping with that. Since you have lots of ingress to the router itself destined for the router, this may not work. I haven't messed with IMQ yet, but it ought to work too. It's just extra work if you don't need to shape incoming traffic for the router itself as well as the network. > Again, many thanks for your suggestions/advice! Enjoy!
Alexander Samad
2004-Oct-06 20:50 UTC
Prioritizing forwarded traffic over locally generated traffic
--BRlT41kksaj93b4P Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi would it be possible to post the scripts that set this up ??? Alex On Fri, Sep 24, 2004 at 05:55:36PM +0100, Neil Greatorex wrote: > Many thanks to both of you for your replies. >=20 > I have managed to get the setup working how I intended now - by using HTB > classes/qdiscs. I had tried this approach before as one of many, however > what I had failed to do was create the two classes I am filtering the > traffic into as subclasses of a parent HTB class that was limited to the > rate of the connection. Now it works as I intended! >=20 > I'm now going to tackle the harder problem of doing it for downloading - = I'm > off to play with IMQ :-) >=20 > Again, many thanks for your suggestions/advice! >=20 > Cheers, > Neil >=20 > -- > #include "sig.h" > #define NAME "Neil Greatorex" > #define E-MAIL "neil@fatboyfat.co.uk"=20 >=20 > http://www.spreadfirefox.com/?q=3Daffiliates&id=3D7889&t=3D58 >=20 > =20 >=20 > > -----Original Message----- > > From: lartc-admin@mailman.ds9a.nl=20 > > [mailto:lartc-admin@mailman.ds9a.nl] On Behalf Of kraquen > > Sent: 24 September 2004 6:36 AM > > To: jasonb@edseek.com > > Cc: lartc@mailman.ds9a.nl > > Subject: Re: [LARTC] Prioritizing forwarded traffic over=20 > > locally generated traffic > >=20 > > Sounds to me like he's trying to match via source IP.. which=20 > > would catch=20 > > everything just fine.. > >=20 > > Niel, > > I do something very similar, its fairly simple.. > >=20 > > you want to mark packets in your prerouting, then match=20 > > against them in=20 > > your qdiscs.. > >=20 > > i use an htb.. my upload link can handle about 85 kilobytes / sec. > >=20 > > I have several classes that match with various rates, the cieling for= =20 > > all of them is ~80 > >=20 > > Then i have a class that matches the mark that i use for that=20 > > specific IP. > >=20 > > That mark goes into a class with a rate of 2 KB/s and a cieling of 75 > >=20 > > that class gets 75 when nothing else is running, and 2 if=20 > > other classes=20 > > are filling it up. > >=20 > > Hope this helps, > > Jason > > Jason Boxman wrote: > >=20 > > >On Thursday 23 September 2004 18:09, Neil Greatorex wrote: > > > =20 > > > > > >>Hi, > > >> > > >>I'm a complete newbie at this traffic shaping / QoS stuff=20 > > so please excuse > > >>me if this is a silly question. I've searched and searched=20 > > on Google and I > > >>just end up confusing myself even more, so I thought I'd=20 > > post my question > > >>to this list and see whether someone can help me! > > >> =20 > > >> > > > > > >Sure. > > > > > > =20 > > > > > >>Basically, I am running a Linux box as a NAT router on my=20 > > home network > > >>(machine name marvin). I want to use mldonkey on the router=20 > > box for P2P > > >>downloads. What I wish to do, is to have any traffic that=20 > > originates on the > > >>internal LAN take priority over traffic that is generated=20 > > from mldonkey on > > >>marvin. I don't wish to restrict the maximum bandwidth for the P2P > > >>downloads on a permanent basis if I can help it - so that=20 > > all the bandwidth > > >>is used all of the time. > > >> =20 > > >> > > > > > >So you'd like to classify p2p traffic from mldonkey=20 > > (Overnet/Kad/eDonkey) such=20 > > >that it is granted a lower priority than other traffic? Not=20 > > a problem. =20 > > >However, because those three protocols use random ports, you=20 > > cannot classify=20 > > >'edonkey' traffic based on port. You can use either ipp2p=20 > > or L7-Filter to=20 > > >match these flows based on layer 7 pattern matching, though. > > > > > > =20 > > > > > >>My plan was to use the PREROUTING and OUTPUT chains of the=20 > > mangle table to > > >>mark the packets, and then use some form of qdisc/class=20 > > structure that will > > >>prioritise one over the other. > > >> =20 > > >> > > > > > >I believe you can use the POSTROUTING chain of the mangle=20 > > table and nab all=20 > > >traffic. L7-Filter has a nice graphic[1] available. > > > > > >[1] http://l7-filter.sourceforge.net/PacketFlow.png > > > > > > =20 > > > > > >>The aim of this is to have an upload that would normally take say 20 > > >>seconds from a machine on the LAN still take 20 seconds=20 > > when mldonkey is > > >>uploading - so the NAT traffic will take all the bandwidth away from > > >>mldonkey. The closer to this aim I can get the better! > > >> =20 > > >> > > > > > >That makes sense, although the time interval is relative to=20 > > the data size and=20 > > >protocol being used, so it isn't a useful measure for the=20 > > rest of us. What's=20 > > >the link size? What's the file / data size? > > > > > > =20 > > > > > >>To test implementations, I am using SFTP to upload a file=20 > > from both a > > >>machine on my internal network (named slartibartfast), and=20 > > marvin (the > > >>router machine) simultaneously. The perfect behaviour would=20 > > be for the > > >>upload on slartibartfast to take 20 seconds, and the upload=20 > > on marvin to > > >>take 40. > > >> =20 > > >> > > > > > >Which implementations have you tried to use? I'd imagine=20 > > Wondershaper? =20 > > >Others? > > > > > > =20 > > > > > >>I have tried various setups of qdiscs and classes, using=20 > > various examples > > >>from all over the web (including the LARTC FAQ/cookbook)=20 > > but I haven't been > > >>able to get anywhere near my aim. All of the attempts I've=20 > > made have led to > > >>both uploads taking near enough 40 seconds, as they are=20 > > both running at 50% > > >>of the available bandwidth. I would like it to give almost all the > > >>bandwidth to slartibartfast for the first 20 seconds, and=20 > > then all the > > >>bandwidth to marvin for the remaining time. > > >> =20 > > >> > > > > > >The problem is likely that you cannot effectively match p2p=20 > > flows that use the=20 > > >'edonkey' protocols. (Actually, the latest L7-Filter=20 > > pattern matches do not=20 > > >yet match eMule's new Kad network, so you'll still need to=20 > > either disable=20 > > >support for that in mldonkey or deal with latency issues that arise.) > > > > > > =20 > > > > > >>I would really appreciate it if someone could tell me whether: > > >>a) This setup is actually possible! > > >> =20 > > >> > > > > > >Absolutely! > > > > > > =20 > > > > > >>b) If using the mangle table chains is correct for this > > >> =20 > > >> > > > > > >I believe so. > > > > > > =20 > > > > > >>c) If it is, the easiest/best/fastest way to implement it.=20 > > Just some hints > > >>for the right direction would be fine! > > >> =20 > > >> > > > > > >You might explore my guide[2]. I have a setup quite similar=20 > > to the one you=20 > > >wish to implement, except on my router does not generate any=20 > > traffic. (I=20 > > >have mldonkey running on an internal machine instead.) > > > > > >[2] http://trekweb.com/~jasonb/articles/traffic_shaping/ > > > > > > =20 > > > > > >>Many thanks in advance, > > >>Neil Greatorex > > >> > > >> =20 > > >> > > > > > >_______________________________________________ > > >LARTC mailing list / LARTC@mailman.ds9a.nl > > >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO:=20 > > http://lartc.org/ > > > =20 > > > > >=20 > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >=20 >=20 >=20 >=20 > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >=20 --BRlT41kksaj93b4P Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBZLz1kZz88chpJ2MRAmgFAKDNv3mB+jrngN4SxLhQxF5r27VO6QCcDAi4 cezmv627EEzL3ZR5azxnWXQ= =Rx31 -----END PGP SIGNATURE----- --BRlT41kksaj93b4P--