hi all,
i am trying to do some advance routing for our clients on a multi route
platform !.. at present am trying on a test bed.. i followed the example
& applied julian's patch to kernel 2.4.19 & have gone thru the docs at
the site... i have defined basically 3 groups for clients--> cache,
cisco, balance.. the name specifies the importance.. this is the details
of what i did-->
[root@Lr1 root]# ip rule ls
0: from all lookup local
10: from EXTnA.124/25 lookup ONE
20: from EXTnB.106/26 lookup TWO
100: from 192.168.1.10 lookup CACHE
101: from 192.168.1.20 lookup CISCO
150: from 192.168.1.30 lookup BALANCE
200: from all lookup ME
32766: from all lookup main
32767: from all lookup 253
[root@Lr1 root]# ip route ls ta ONE
default via EXtnA.1 dev eth1 src EXTnA.124
prohibit default proto static metric 1
[root@Lr1 root]# ip route ls ta TWO
default via EXTnB.70 dev eth0 src EXTnB.106
prohibit default proto static metric 1
[root@Lr1 root]# ip route ls ta CACHE
default via EXTnA.1 dev eth1
prohibit default proto static metric 1
[root@Lr1 root]# ip route ls ta CISCO
default via EXTnB.70 dev eth0
prohibit default proto static metric 1
[root@Lr1 root]# ip route ls ta BALANCE
default
nexthop via EXTnB.70 dev eth0 weight 1
nexthop via EXTnA.1 dev eth1 weight 1
prohibit default proto static metric 1
[root@Lr1 root]# ip route ls ta ME
default
nexthop via EXTnA.1 dev eth1 weight 1
nexthop via EXTnB.70 dev eth0 weight 1
prohibit default proto static metric 1
[root@Lr1 root]# ip addr ls
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:50:bf:4b:f7:84 brd ff:ff:ff:ff:ff:ff
inet EXTnB.106/26 brd EXTnB.127 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:80:c8:b9:69:99 brd ff:ff:ff:ff:ff:ff
inet EXTnA.124/25 brd EXTnA.127 scope global eth1
4: eth2: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:80:c8:b9:69:9a brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/16 brd 192.168.255.255 scope global eth2
[root@Lr1 root]# ip route ls
203.163.146.64/26 dev eth0 scope link
203.163.149.0/25 dev eth1 scope link
192.168.0.0/16 dev eth2 proto kernel scope link src 192.168.0.1
127.0.0.0/8 dev lo scope link
here ONE & TWO are the two external links.. ME is used for local server
DNS deamon.. the other three viz CACHE CISCO BALANCE are the routes the
clients ip's must follow.. i have enabled ip_forward .. & iptables rules
are also specified correct .. i.e according to the ip..
BUT am **NOT** able to surf at all from internal network... not even
able to ping eth2 !!!.. default INPUT & OUTPUT are set to ACCEPT while
FORWARD is DROP..
whats missing there ?.. after trying all day i want guidance now...
awaiting a reply very anxiously....
A.H
Hello, On Mon, 19 Aug 2002, Arindam Haldar wrote: > & applied julian's patch to kernel 2.4.19 & have gone thru the docs at > the site... i have defined basically 3 groups for clients--> cache, > cisco, balance.. the name specifies the importance.. this is the details > of what i did--> Carefully analyze the docs... > [root@Lr1 root]# ip rule ls > 0: from all lookup local # direct communications are first priority ip rule add prio 5 table main > 10: from EXTnA.124/25 lookup ONE > 20: from EXTnB.106/26 lookup TWO > 100: from 192.168.1.10 lookup CACHE > 101: from 192.168.1.20 lookup CISCO > 150: from 192.168.1.30 lookup BALANCE > 200: from all lookup ME > 32766: from all lookup main > 32767: from all lookup 253 > BUT am **NOT** able to surf at all from internal network... not even > able to ping eth2 !!!.. default INPUT & OUTPUT are set to ACCEPT while > FORWARD is DROP.. First try with all ACCEPT. > whats missing there ?.. after trying all day i want guidance now... > awaiting a reply very anxiously.... Your setup is a bit strange: internal hosts use some gateways, the external addresses use different gateways. The problem is that if you are using NAT and for example 192.168.1.10 is SNAT-ed the packet will leave with new saddr (the masquerade address). Looking in your rules there is different gateway for the masquerade address. This can't work. The current framework requires that: - if one internal IP is masqueraded to a specific address, you need the 2 routes to be similar, i.e.: from INT_IP to TARGET and from MASQ_IP to TARGET to use same gateway and device. This is even mandatory for the patches. Currently, the first packet for one connection is routed via the route "from INT_IP to TARGET", the SNAT rules assign masquerade address at postrouting and then all next packets are routed via the 2nd route - 1 route per forwarded packet. It is a bit strange these two routes to use different gateways. Do you have a good reason for this? Also note that rules in the form "from 0/0 to ANY_TARGET" where ANY_TARGET can be any subnet including 0/0 are used for source address autoselection - the resulting preferred source IP is used as saddr. It is not used only as "default" rule. So, playing tricks with different gateways is not possible. The setup is ambiguous if NAT is involved. > A.H Regards -- Julian Anastasov <ja@ssi.bg>
does anyone know about HTB shaping in a bridging machine? I currently run my shaper box as bridge and something is going strange, such as a class cannot send at rate it supposed to. I mean if anyone know something about bridging and its htb shaping behavior. thanks in advance. __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com
On Tue, 20 Aug 2002, zain arrifa'i wrote:
> does anyone know about HTB shaping in a bridging
> machine?
> I currently run my shaper box as bridge and something
> is going strange, such as a class cannot send at rate
> it supposed to.
> I mean if anyone know something about bridging and its
> htb shaping behavior.
> thanks in advance.
I don't know about HTB but I had such configuration:
,------------------------------.
| ,-- eth0 -+--> Seg1
INET ----+-> ppp0 -- ROUTER --+ (bridge)|
| (fwall) `-- eth1 -+--> Seg2
`------------------------------'
and I succeded in firewalling and shaping one of the segments with CBQ
(just limiting to some rate, in this example INET=192kbit, seg1=64kbit).
It just worked, of course after applying the correct patches fr bridge
firewalling into the kernel...
--
##########################################
# | p0wer | #
# __ | GG#1877248 | #
# (oo) | p0wer@bojko.eu.org | #
# / \/ \ Go away or I will replace you #
# `V__V' with a very small shell script. #
##########################################