Re: [mpls-linux-general] How to separate tcp traffic from udp traffic using MPLS
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
Re: [mpls-linux-general] How to separate tcp traffic from udp traffic using MPLS
|
From: James R. L. <jl...@mi...> - 2005-12-07 17:44:43
|
If you are going to do performance tests make sure to use a kernel MPLS debugging turned off. Let me know if you need details. On Wed, Dec 07, 2005 at 03:37:49PM -0200, Carlos Marcos Kakihara wrote: > ** Sorry, Im not an ascii art expert, and html email doesnt help. :-) > HOST1 and HOST2 are outside of MPLS network, and they are generating > traffic through LSR1 and LSR5 (LERs), respectively. > All the transit LSRs have no default route and no IP forwarding (sysctl= -w > net.ipv4.ip_forward=3D0). Only LERs have IP forwarding enabled. > Now Ill start to build some stress tests (I was very stressed already, = now > it is MPLS's turn ;-) ). >=20 > Thank you very much for your help. >=20 > On 12/7/05, James R. Leu <jl...@mi...> wrote: > > > > I've never used the FORWARD chain, but I think it will be fine. Are you > > generating traffic locally on the LER or is the traffic your working wi= th > > being forward through the LER? That might explain the difference. > > > > On Wed, Dec 07, 2005 at 02:39:17PM -0200, Carlos Marcos Kakihara wrote: > > > It worked, but i had to use a FORWARD chain in iptables, because > > adding a > > > -j LOG alone onto OUTPUT chain produced no log in syslog. So, I guess > > that > > > packets are not matching the OUTPUT chain. > > > I also changed ip route syntax. Im using one 'ip route add' with 2 > > > nexthop, without spec_nh values: > > > > > > lsr1:~# ip route add 10.28.1.0/24 nexthop via 192.168.28.2 nexthop via > > > 192.168.29.2 > > > lsr1:~# iptables -A FORWARD -p icmp -d 10.28.1.0/24 -j spec_nh --spec= _nh > > > 0x8847:0x00000002 > > > lsr1:~# iptables -A FORWARD -p tcp -d 10.28.1.0/24 -j spec_nh --spec_= nh > > > 0x8847:0x00000003 > > > > > > Now tcpdump shows right labels in both LSPs. > > > Is it ok to use the FORWARD chain? > > > > > > Thank you. > > > > > > On 12/7/05, James R. Leu <jl...@mi...> wrote: > > > > > > > > I would get rid of the FTNs create via 'ip route'. You will still > > need to > > > > have a prefix in your table for that destination, but it only needs= to > > > > have > > > > one next hop and doesn't need to have a spec_nh specified. > > > > > > > > This will allow iptable to do the work. My guess is that there is > > some > > > > confusion with both iptables and 'ip route' trying to add labels to > > the > > > > same packets. > > > > > > > > On Wed, Dec 07, 2005 at 01:50:05AM -0200, Carlos Marcos Kakihara > > wrote: > > > > > Hi. > > > > > Im trying to create 2 lsp in a fish network: one for tcp and one > > for > > > > icmp > > > > > (for tests). I have used courier new font to see the picture. > > > > > > > > > > +------+ +------+ > > > > > 0| LSR2 |1----0| LSR3 |1 > > > > > / +------+ +------+ \ > > > > > / \ > > > > > / \ > > > > > +-------+ +------+2 1+------+ > > > > +-------+ > > > > > | HOST1 |0---0| LSR1 | | LSR5 |0--= -0| > > > > HOST2 | > > > > > +-------+ +------+1 2+------+ > > > > +-------+ > > > > > \ / > > > > > \ / > > > > > \ +------+ / > > > > > X------0| LSR4 |1------X > > > > > +------+ > > > > > > > > > > HOST1: > > > > > sis0: inet 10.28.0.2 netmask 0xffffff00 broadcast 10.28.0.255 > > > > > > > > > > LSR1: > > > > > eth0:1 (alias) -> 10.28.0.1 > > > > > eth1 -> 192.168.29.1 > > > > > eth2 -> 192.168.28.1 > > > > > > > > > > LSR2: > > > > > eth0 -> 192.168.28.2 > > > > > eth1 -> 192.168.28.33 > > > > > > > > > > LSR3: > > > > > eth0 -> 192.168.28.34 > > > > > eth1 -> 192.168.28.65 > > > > > > > > > > LSR4: > > > > > eth0 -> 192.168.29.2 > > > > > eth1 -> 192.168.29.33 > > > > > > > > > > LSR5: > > > > > eth0:1 (alias) -> 10.28.1.1 > > > > > eth1 -> 192.168.28.66 > > > > > eth2 -> 192.168.29.34 > > > > > > > > > > HOST2: > > > > > # ifconfig > > > > > ed0: inet 10.28.1.2 netmask 0xffffff00 broadcast 10.28.1.255 > > > > > > > > > > LSP A: LSR1 -> LSR2 -> LSR3 -> LSR5 > > > > > LSP B: LSR1 -> LSR4 -> LSR5 > > > > > > > > > > The numbers are the ethernet interfaces id: 0 means eth0 (or > > sis0), 1 > > > > > means eth1 and 2 means eth2. > > > > > All 192.168 networks have 255.255.255.224 netmask. > > > > > > > > > > Ive tried the following: > > > > > > > > > > lsr1:~# uname -a > > > > > Linux lsr1 2.6.9-MPLSv2-LSR1 #1 Tue Nov 22 23:06:08 BRST 2005 i686 > > > > GNU/Linux > > > > > lsr1:~# cat /sys/mpls/version > > > > > 1.946 > > > > > lsr1:~# mpls nhlfe add key 0 > > > > > Key: 0x00000002 > > > > > lsr1:~# mpls nhlfe change key 0x00000002 instructions push gen 10= 004 > > > > nexthop > > > > > eth2 ipv4 192.168.28.2 > > > > > lsr1:~# mpls nhlfe add key 0 > > > > > Key: 0x00000003 > > > > > lsr1:~# mpls nhlfe change key 0x00000003 instructions push gen 10= 000 > > > > nexthop > > > > > eth1 ipv4 192.168.29.2 > > > > > lsr1:~# mpls labelspace add dev eth2 labelspace 0 > > > > > lsr1:~# mpls labelspace add dev eth1 labelspace 0 > > > > > lsr1:~# mpls ilm add label gen 10005 > > > > > lsr1:~# mpls ilm add label gen 10001 > > > > > > > > > > lsr1:~# mpls nhlfe show > > > > > NHLFE entry key 0x00000003 mtu 1496 propagate_ttl > > > > > push gen 10000 set eth1 ipv4 192.168.29.2 (0 bytes, 0 pk= ts, > > 0 > > > > > dropped) > > > > > NHLFE entry key 0x00000002 mtu 1496 propagate_ttl > > > > > push gen 10004 set eth2 ipv4 192.168.28.2 (0 bytes, 0 pk= ts, > > 0 > > > > > dropped) > > > > > lsr1:~# mpls ilm show > > > > > ILM entry label gen 10001 labelspace 0 proto ipv4 > > > > > pop peek (0 bytes, 0 pkts, 0 dropped) > > > > > ILM entry label gen 10005 labelspace 0 proto ipv4 > > > > > pop peek (0 bytes, 0 pkts, 0 dropped) > > > > > lsr1:~# mpls labelspace show > > > > > LABELSPACE entry dev eth0 labelspace -1 > > > > > LABELSPACE entry dev lo labelspace -1 > > > > > LABELSPACE entry dev eth1 labelspace 0 > > > > > LABELSPACE entry dev eth2 labelspace 0 > > > > > LABELSPACE entry dev tunl0 labelspace -1 > > > > > LABELSPACE entry dev atm0 labelspace -1 > > > > > LABELSPACE entry dev lec0 labelspace -1 > > > > > > > > > > lsr1:~# ip route add 10.28.1.0/24 nexthop via 192.168.28.2 spec_nh > > > > 0x8847 > > > > > 0x2 > > > > > lsr1:~# ip route append 10.28.1.0/24 nexthop via 192.168.29.2spec= _nh > > > > 0x8847 > > > > > 0x3 > > > > > lsr1:~# iptables -A OUTPUT -p tcp -d 10.28.1.0/24 -j spec_nh > > --spec_nh > > > > > 0x8847:0x3 > > > > > lsr1:~# iptables -A OUTPUT -p icmp -d 10.28.1.0/24 -j spec_nh > > --spec_nh > > > > > 0x8847:0x2 > > > > > > > > > > lsr1:~# ip route list > > > > > 192.168.29.0/27 dev eth1 proto kernel scope link src 192.168.2= 9.1 > > > > > 192.168.28.0/27 dev eth2 proto kernel scope link src 192.168.2= 8.1 > > > > > 10.28.1.0/24 via 192.168.28.2 dev eth2 spec_nh 0x8847 0x00000002 > > > > > 10.28.1.0/24 via 192.168.29.2 dev eth1 spec_nh 0x8847 0x00000003 > > > > > 10.28.0.0/24 dev eth0 proto kernel scope link src 10.28.0.1 > > > > > 172.30.0.0/16 dev atm0 proto kernel scope link src 172.30.28.1 > > > > > 172.29.0.0/16 dev lec0 proto kernel scope link src 172.29.28.1 > > > > > > > > > > lsr1:~# iptables -L -n > > > > > Chain INPUT (policy ACCEPT) > > > > > target prot opt source destination > > > > > > > > > > Chain FORWARD (policy ACCEPT) > > > > > target prot opt source destination > > > > > > > > > > Chain OUTPUT (policy ACCEPT) > > > > > target prot opt source destination > > > > > spec_nh tcp -- 0.0.0.0/0 10.28.1.0/24 set > > spec_nh > > > > > 0x4788:0x00000003 > > > > > spec_nh icmp -- 0.0.0.0/0 10.28.1.0/24 set > > spec_nh > > > > > 0x4788:0x00000002 > > > > > > > > > > > > > > > At this point, I think icmp goes through LSP A and tcp goes > > through > > > > LSP B. > > > > > When I ping HOST2 (10.28.1.2) from HOST1 (10.28.0.2), tcpdump at > > LSR1 > > > > shows > > > > > label 10004, indicating the use of LSP A. But when I do a ssh, the > > label > > > > > 10004 appears again, indicating that LSP B IS NOT in use. > > > > > If I flush iptables rules and delete the route through LSP A, a= ll > > > > trafic > > > > > goes through LSP B. > > > > > Can someone see what Im doing wrong? Maybe some routes cache? Or > > ip > > > > route > > > > > syntax? > > > > > > > > > > TIA. > > > > > > > > > > > > > > > On 12/5/05, James R. Leu <jl...@mi...> wrote: > > > > > > MPLS-linux builds on the existing netfilter (iptables) > > infrastructure > > > > > > that exists in the linux kernel. > > > > > > > > > > > > After building/installing a MPLS enabled iptables you can do: > > > > > > > > > > > > iptables -A OUTPUT -p tcp -j spec_nh --spec_nh 0x8847:0x2 > > > > > > > > > > > > This maps all TCP traffic to the special nexthop 0x8847:0x2, wh= ere > > > > > > 0x8847 mean MPLS and 0x2 mean NHLFE with the key of 0x2. > > > > > > > > > > > > Basically if you can build an iptables rules to do what you want > > at > > > > > > L3, then you can simply add the spec_nh target and it will map = to > > > > MPLS. > > > > > > > > > > > > On Mon, Dec 05, 2005 at 07:34:28PM +0000, Carlos Veiga wrote: > > > > > > > Hello, > > > > > > > > > > > > > > I?m studying MPLS using the project mpls-linux to mount some > > > > > testbeds networks and analyze the Traffic Engineering capabiliti= es > > of > > > > MPLS. > > > > > Some papers results show that the TCP traffic is affected by UDP > > > > traffic > > > > > in the core of MPLS networks. > > > > > > > > > > > > > > I?m trying to separate the UDP traffic from the TCP traffic > > using > > > > > two differents LSP?s. I would like to know how can I do that usi= ng > > > > > the mpls(ip route/iptables with mpls patch) command. I?m know how > > to > > > > > create static LSP?s based on the destination IP to determine the > > path > > > > > of packets, but I don?t know how to determine the path based on > > > > > the protocol (tcp/udp). > > > > > > > > > > > > > > > > > > > > > Figure of my network topology: > > > > > > > > > > > > > > > > > > > > > LSP1(TCP) ---> > > > > > > > > > > > > > > _____LSRC_____ > > > > > > > / \ > > > > > > > / \ > > > > > > > ---LER A---LSRB LSRE----LER F > > > > > > > \ / > > > > > > > \_____LSRD_____/ > > > > > > > > > > > > > > > > > > > > > LSP2(UDP) ---> > > > > > > > > > > > > > > > > > > > > > Thanks for any help. > > --=20 James R. Leu jl...@mi... |
