Thread: [mpls-linux-devel] cannot remove iptables rule with mpls target / cannot remove nhlfe key used by i
Status: Beta
Brought to you by:
jleu
Menu
▾
▴
mpls-linux-devel
|
From: Tom K. <t.k...@gm...> - 2007-12-12 13:19:18
|
Hello, I came across a problem with removing an mpls target from iptables. Apparently, the problem was found previously and posted on the mailing list: http://sourceforge.net/mailarchive/message.php?msg_id=58990.192.168.1.72.1177109560.squirrel%40webmail.larces.uece.br http://sourceforge.net/mailarchive/message.php?msg_id=1801039839.20070421093542%40s2001.tu-chemnitz.de http://sourceforge.net/mailarchive/message.php?msg_id=4631EBCD.8090708%40gmail.com The target can be removed from iptables only by using the rule number instead of the complete rule description. Unfortunately, I encountered another issue, which could be related to this one. Namely, when a nhfle key has been used by an iptables target and the iptables rule is later removed, then the key can no longer be removed from the nhlfe table. The key can now only be removed from the nhlfe table by rebooting the pc. The following commands will show the error. mpls nhlfe add key 0 iptables -t mangle -A OUTPUT <some rule> -j mpls --nhlfe <key> iptables -t mangle -D OUTPUT <#some rule> mpls nhlfe del key <key> The last command will report the error: RTNETLINK answers: Device or resource busy dmesg reports: MPLS DEBUG net/mpls/mpls_nhlfe.c:468:mpls_del_out_label: enter MPLS DEBUG net/mpls/mpls_nhlfe.c:492:mpls_del_out_label: Node 4 is being used MPLS DEBUG net/mpls/mpls_nhlfe.c:493:mpls_del_out_label: exit MPLS DEBUG net/mpls/mpls_netlink.c:346:genl_mpls_nhlfe_del: Exit: -16 Can anyone confirm this problem and is there a solution/workaround? Kind regards, Tom t.k...@gm... |
|
From: James R. L. <jl...@mi...> - 2007-12-12 14:31:29
|
On Wed, Dec 12, 2007 at 02:12:30PM +0100, Tom Kleiberg wrote: > Hello, >=20 > I came across a problem with removing an mpls target from iptables. > Apparently, the problem was found previously and posted on the mailing li= st: > http://sourceforge.net/mailarchive/message.php?msg_id=3D58990.192.168.1.7= 2.1177109560.squirrel%40webmail.larces.uece.br > http://sourceforge.net/mailarchive/message.php?msg_id=3D1801039839.200704= 21093542%40s2001.tu-chemnitz.de > http://sourceforge.net/mailarchive/message.php?msg_id=3D4631EBCD.8090708%= 40gmail.com Completely different problem. In those posts they couldn't even create ipt= ables rules. It was due to a change in kernel structures for netfilter targets. This is the first I'm hearing of your issue. Can you please provide details about the MPLS version, iptables version, an= d linux distribution you are using. > The target can be removed from iptables only by using the rule number > instead of the complete rule description. >=20 > Unfortunately, I encountered another issue, which could be related to this > one. Namely, when a nhfle key has been used by an iptables target and the > iptables rule is later removed, > then the key can no longer be removed from the nhlfe table. The key can n= ow > only be removed from the nhlfe table by > rebooting the pc. >=20 > The following commands will show the error. > mpls nhlfe add key 0 > iptables -t mangle -A OUTPUT <some rule> -j mpls --nhlfe <key> > iptables -t mangle -D OUTPUT <#some rule> > mpls nhlfe del key <key> >=20 > The last command will report the error: > RTNETLINK answers: Device or resource busy What happens if you do a iptables -F instead of trying to remove just the single rule? > dmesg reports: > MPLS DEBUG net/mpls/mpls_nhlfe.c:468:mpls_del_out_label: enter > MPLS DEBUG net/mpls/mpls_nhlfe.c:492:mpls_del_out_label: Node 4 is being > used > MPLS DEBUG net/mpls/mpls_nhlfe.c:493:mpls_del_out_label: exit > MPLS DEBUG net/mpls/mpls_netlink.c:346:genl_mpls_nhlfe_del: Exit: -16 >=20 > Can anyone confirm this problem and is there a solution/workaround? >=20 > Kind regards, >=20 > Tom > t.k...@gm... > ------------------------------------------------------------------------- > SF.Net email is sponsored by:=20 > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > mpls-linux-general mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-general --=20 James R. Leu jl...@mi... |
|
From: Tom K. <t.k...@gm...> - 2007-12-12 14:55:19
|
Hello James, Thanks for your time. I'm using the pre-built rpms for FC6 (on FC6) version 1.958 that are available on SourceForge, i.e. the kernel,iptables etc. I have tried several ways to workaround the problem and so far no success. Flushing the chain will not work. Using a custom chain, and flushing and deleting that afterwards also will not work. Kind regards, Tom On Dec 12, 2007, at 3:25 PM, James R. Leu wrote: > On Wed, Dec 12, 2007 at 02:12:30PM +0100, Tom Kleiberg wrote: >> Hello, >> >> I came across a problem with removing an mpls target from iptables. >> Apparently, the problem was found previously and posted on the >> mailing list: >> http://sourceforge.net/mailarchive/message.php?msg_id=58990.192.168.1.72.1177109560.squirrel%40webmail.larces.uece.br >> http://sourceforge.net/mailarchive/message.php?msg_id=1801039839.20070421093542%40s2001.tu-chemnitz.de >> http://sourceforge.net/mailarchive/message.php?msg_id=4631EBCD.8090708%40gmail.com > > Completely different problem. In those posts they couldn't even > create iptables > rules. It was due to a change in kernel structures for netfilter > targets. > This is the first I'm hearing of your issue. > > Can you please provide details about the MPLS version, iptables > version, and linux > distribution you are using. > >> The target can be removed from iptables only by using the rule number >> instead of the complete rule description. >> >> Unfortunately, I encountered another issue, which could be related >> to this >> one. Namely, when a nhfle key has been used by an iptables target >> and the >> iptables rule is later removed, >> then the key can no longer be removed from the nhlfe table. The key >> can now >> only be removed from the nhlfe table by >> rebooting the pc. >> >> The following commands will show the error. >> mpls nhlfe add key 0 >> iptables -t mangle -A OUTPUT <some rule> -j mpls --nhlfe <key> >> iptables -t mangle -D OUTPUT <#some rule> >> mpls nhlfe del key <key> >> >> The last command will report the error: >> RTNETLINK answers: Device or resource busy > > What happens if you do a iptables -F instead of trying to remove > just the single rule? > >> dmesg reports: >> MPLS DEBUG net/mpls/mpls_nhlfe.c:468:mpls_del_out_label: enter >> MPLS DEBUG net/mpls/mpls_nhlfe.c:492:mpls_del_out_label: Node 4 is >> being >> used >> MPLS DEBUG net/mpls/mpls_nhlfe.c:493:mpls_del_out_label: exit >> MPLS DEBUG net/mpls/mpls_netlink.c:346:genl_mpls_nhlfe_del: Exit: -16 >> >> Can anyone confirm this problem and is there a solution/workaround? >> >> Kind regards, >> >> Tom >> t.k...@gm... > >> ------------------------------------------------------------------------- >> SF.Net email is sponsored by: >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> _______________________________________________ >> mpls-linux-general mailing list >> mpl...@li... >> https://lists.sourceforge.net/lists/listinfo/mpls-linux-general > > > -- > James R. Leu > jl...@mi... |
|
From: James R. L. <jl...@mi...> - 2007-12-13 05:31:30
|
Just wanted to confirm that I'm seeing this issue on mpls-linux 1.958 on FC6 (and F7 and F8). I will dig into it. On Wed, Dec 12, 2007 at 03:55:11PM +0100, Tom Kleiberg wrote: > Hello James, >=20 > Thanks for your time. I'm using the pre-built rpms for FC6 (on FC6) =20 > version 1.958 that are available on SourceForge, i.e. the =20 > kernel,iptables etc. I have tried several ways to workaround the =20 > problem and so far no success. Flushing the chain will not work. Using = =20 > a custom chain, and flushing and deleting that afterwards also will =20 > not work. >=20 > Kind regards, >=20 > Tom >=20 >=20 >=20 > On Dec 12, 2007, at 3:25 PM, James R. Leu wrote: >=20 > >On Wed, Dec 12, 2007 at 02:12:30PM +0100, Tom Kleiberg wrote: > >>Hello, > >> > >>I came across a problem with removing an mpls target from iptables. > >>Apparently, the problem was found previously and posted on the =20 > >>mailing list: > >>http://sourceforge.net/mailarchive/message.php?msg_id=3D58990.192.168.1= .72.1177109560.squirrel%40webmail.larces.uece.br > >>http://sourceforge.net/mailarchive/message.php?msg_id=3D1801039839.2007= 0421093542%40s2001.tu-chemnitz.de > >>http://sourceforge.net/mailarchive/message.php?msg_id=3D4631EBCD.809070= 8%40gmail.com > > > >Completely different problem. In those posts they couldn't even =20 > >create iptables > >rules. It was due to a change in kernel structures for netfilter =20 > >targets. > >This is the first I'm hearing of your issue. > > > >Can you please provide details about the MPLS version, iptables =20 > >version, and linux > >distribution you are using. > > > >>The target can be removed from iptables only by using the rule number > >>instead of the complete rule description. > >> > >>Unfortunately, I encountered another issue, which could be related =20 > >>to this > >>one. Namely, when a nhfle key has been used by an iptables target =20 > >>and the > >>iptables rule is later removed, > >>then the key can no longer be removed from the nhlfe table. The key =20 > >>can now > >>only be removed from the nhlfe table by > >>rebooting the pc. > >> > >>The following commands will show the error. > >>mpls nhlfe add key 0 > >>iptables -t mangle -A OUTPUT <some rule> -j mpls --nhlfe <key> > >>iptables -t mangle -D OUTPUT <#some rule> > >>mpls nhlfe del key <key> > >> > >>The last command will report the error: > >>RTNETLINK answers: Device or resource busy > > > >What happens if you do a iptables -F instead of trying to remove > >just the single rule? > > > >>dmesg reports: > >>MPLS DEBUG net/mpls/mpls_nhlfe.c:468:mpls_del_out_label: enter > >>MPLS DEBUG net/mpls/mpls_nhlfe.c:492:mpls_del_out_label: Node 4 is =20 > >>being > >>used > >>MPLS DEBUG net/mpls/mpls_nhlfe.c:493:mpls_del_out_label: exit > >>MPLS DEBUG net/mpls/mpls_netlink.c:346:genl_mpls_nhlfe_del: Exit: -16 > >> > >>Can anyone confirm this problem and is there a solution/workaround? > >> > >>Kind regards, > >> > >>Tom > >>t.k...@gm... > > > >>-----------------------------------------------------------------------= -- > >>SF.Net email is sponsored by: > >>Check out the new SourceForge.net Marketplace. > >>It's the best place to buy or sell services for > >>just about anything Open Source. > >>http://sourceforge.net/services/buy/index.php > >>_______________________________________________ > >>mpls-linux-general mailing list > >>mpl...@li... > >>https://lists.sourceforge.net/lists/listinfo/mpls-linux-general > > > > > >--=20 > >James R. Leu > >jl...@mi... --=20 James R. Leu jl...@mi... |
|
From: Tom K. <t.k...@gm...> - 2007-12-20 14:23:11
|
Hello all, I have run into another problem with iptables. However, I am not fully certain if it is related to the mpls implementation or possibly an iptables bug. The following is happening: 1. I set up an explicit LSP using the mpls cli 2. create a rule in the mangle table, POSTROUTING chain, where the target is the mpls key. Furthermore, I use a filter expression where I filter on the protocol, source and destination ipaddress and portnumbers. 3. Now, when I send packets from this node to the destination, and use tcpdump to monitor the packets, I correctly see the MPLS packets appearing. So far, so good. But when I use another portnumber or protocol to send the packets (without changing the iptables rule), I STILL see MPLS packets. Moreover, when I remove the rule from the IPTABLES but not the LSP, I still see the MPLS packets. This is unwanted behavior, I think. I have also tried sending packets at different portnumbers BEFORE sending any packet over the LSP, and then the behavior is as expected, namely that there are no MPLS packets created. After the LSP is removed, the MPLS packets correctly disappear. As I said earlier, I am not sure if it is an iptables problem, because to test it, I require some other mangle target and sofar MPLS is the only I have up and running. Perhaps anybody can confirm this behavior? I am using the 1.959 version of mpls linux together with FC6. p.s. The problem also occurs for the OUTPUT chain. Kind regards, Tom t.k...@gm... |
|
From: James R. L. <jl...@mi...> - 2007-12-20 14:32:36
|
On Thu, Dec 20, 2007 at 03:23:05PM +0100, Tom Kleiberg wrote: > Hello all, >=20 > I have run into another problem with iptables. However, I am not fully = =20 > certain if it is related to the mpls implementation or possibly an =20 > iptables bug. The following is happening: >=20 > 1. I set up an explicit LSP using the mpls cli > 2. create a rule in the mangle table, POSTROUTING chain, where the =20 > target is the mpls key. Furthermore, I use a filter expression where I = =20 > filter on the protocol, source and destination ipaddress and =20 > portnumbers. > 3. Now, when I send packets from this node to the destination, and use = =20 > tcpdump to monitor the packets, I correctly see the MPLS packets =20 > appearing. >=20 > So far, so good. But when I use another portnumber or protocol to send = =20 > the packets (without changing the iptables rule), I STILL see MPLS =20 > packets. Moreover, when I remove the rule from the IPTABLES but not =20 > the LSP, I still see the MPLS packets. This is unwanted behavior, I =20 The issue you mention about removing the rule not stopping the flow on the LSP is a known issue. It is because iptables does not flush the route cache after removing rules. It's been awhile since I look at that issue. Can you try manually flushing the route cache after removing the iptables and see it that 'fixes' it? As for your other issue where other ports are being matched by the same iptables rule. I haven't heard of that before. Please give example commands so I can duplicate that one. > think. I have also tried sending packets at different portnumbers =20 > BEFORE sending any packet over the LSP, and then the behavior is as =20 > expected, namely that there are no MPLS packets created. That is because MPLS flushes the route cache when it removes NHLFE. > After the LSP is removed, the MPLS packets correctly disappear. >=20 > As I said earlier, I am not sure if it is an iptables problem, because = =20 > to test it, I require some other mangle target and sofar MPLS is the =20 > only I have up and running. Perhaps anybody can confirm this behavior? >=20 > I am using the 1.959 version of mpls linux together with FC6. >=20 > p.s. The problem also occurs for the OUTPUT chain. >=20 > Kind regards, >=20 > Tom > t.k...@gm... >=20 >=20 > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > mpls-linux-devel mailing list > mpl...@li... > https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel --=20 James R. Leu jl...@mi... |
|
From: Tom K. <t.k...@gm...> - 2007-12-20 15:07:34
|
Ok, here's some output:
First, I create the LSP. The show commands then give this (this all is
only at the source node):
[root@london ~]# mpls nhlfe show;mpls ilm show;mpls xc show
NHLFE entry key 0x0000000d mtu 1496 propagate_ttl
push gen 2001 set eth0 ipv4 10.0.0.2 (5953 bytes, 55 pkts)
[root@london ~]# iptables -t mangle -vnL POSTROUTING
Chain POSTROUTING (policy ACCEPT 1572K packets, 989M bytes)
pkts bytes target prot opt in out source
destination
[root@london ~]#
then I install the iptables rule:
sudo /sbin/iptables -t mangle -A POSTROUTING -s 10.0.0.1 -d 10.0.0.10 -
p udp --source-port 4001 --destination-port 4001 -j mpls --nhlfe 0xd
and I get following output:
[root@london ~]# iptables -t mangle -vnL POSTROUTING
Chain POSTROUTING (policy ACCEPT 1572K packets, 989M bytes)
pkts bytes target prot opt in out source
destination
0 0 mpls udp -- * * 10.0.0.1
10.0.0.10 udp spt:4001 dpt:4001 nhlfe 0xd
Then I generate trafffic with d-itg, source-port 4000, dest-port 4001
./ITGSend -a 10.0.0.10 -sp 4000 -rp 4001 -T udp -C 100 -c 100 -t 200
this tg may be less known, I know it functions correct. tcpdump now
provides me:
[root@london ~]# tcpdump -n -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
15:55:57.273472 IP 10.0.0.2 > 224.0.0.5: OSPFv2, Hello, length: 48
15:55:57.603225 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 64
15:55:57.603774 IP 10.0.0.10.cslistener > 10.0.0.1.49535: S
1050046578:1050046578(0) ack 807773929 win 5792 <mss
1460,sackOK,timestamp 19088753 91726072,nop,wscale 6>
15:55:57.603818 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 56
15:55:57.604142 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 57
15:55:57.604520 IP 10.0.0.10.cslistener > 10.0.0.1.49535: . ack 2 win
91 <nop,nop,timestamp 19088753 91726073>
15:55:57.604772 IP 10.0.0.10.cslistener > 10.0.0.1.49535: P 1:2(1) ack
2 win 91 <nop,nop,timestamp 19088753 91726073>
15:55:57.604791 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 56
15:55:57.605121 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 88
15:55:57.605770 IP 10.0.0.10.cslistener > 10.0.0.1.49535: P 2:7(5) ack
34 win 91 <nop,nop,timestamp 19088755 91726074>
15:55:57.605793 IP 10.0.0.10.ssh > 10.0.0.1.59039: P
3912795675:3912795739(64) ack 3675589473 win 202 <nop,nop,timestamp
19088755 91641952>
15:55:57.605810 IP 10.0.0.1.59039 > 10.0.0.10.ssh: . ack 64 win 901
<nop,nop,timestamp 91726074 19088755>
15:55:57.629558 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.639542 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.644828 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 56
15:55:57.649531 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.659535 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.669530 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.679529 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.689529 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.699528 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.709527 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.719529 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.729530 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.739529 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.749529 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.759529 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.769530 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.779530 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.789528 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.799528 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.809527 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.819528 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 132
15:55:57.829699 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 61
15:55:57.830388 IP 10.0.0.10.ssh > 10.0.0.1.59039: P 64:128(64) ack 1
win 202 <nop,nop,timestamp 19088970 91726074>
15:55:57.830415 IP 10.0.0.1.59039 > 10.0.0.10.ssh: . ack 128 win 901
<nop,nop,timestamp 91726299 19088970>
15:55:57.871862 IP 10.0.0.10.cslistener > 10.0.0.1.49535: . ack 39 win
91 <nop,nop,timestamp 19089010 91726298>
15:55:58.636585 IP 10.0.0.1 > 224.0.0.5: OSPFv2, Hello, length: 48
15:55:58.830796 IP 10.0.0.10.cslistener > 10.0.0.1.49535: P 7:12(5)
ack 39 win 91 <nop,nop,timestamp 19089932 91726298>
15:55:58.830837 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 56
15:55:58.830886 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 57
15:55:58.831542 IP 10.0.0.10.cslistener > 10.0.0.1.49535: . ack 40 win
91 <nop,nop,timestamp 19089933 91727300>
15:55:58.831560 IP 10.0.0.10.cslistener > 10.0.0.1.49535: P 12:13(1)
ack 40 win 91 <nop,nop,timestamp 19089933 91727300>
15:55:58.831570 IP 10.0.0.10.cslistener > 10.0.0.1.49535: F 13:13(0)
ack 40 win 91 <nop,nop,timestamp 19089933 91727300>
15:55:58.831612 MPLS (label 2001, exp 0, [S], ttl 64), IP, length: 56
15:55:58.832043 IP 10.0.0.10.cslistener > 10.0.0.1.49535: . ack 41 win
91 <nop,nop,timestamp 19089933 91727301>
15:56:02.602053 arp who-has 10.0.0.1 tell 10.0.0.2
15:56:02.602068 arp reply 10.0.0.1 is-at 00:08:74:ad:25:01
15:56:07.274025 IP 10.0.0.2 > 224.0.0.5: OSPFv2, Hello, length: 48
15:56:08.637429 IP 10.0.0.1 > 224.0.0.5: OSPFv2, Hello, length: 48
15:56:17.274825 IP 10.0.0.2 > 224.0.0.5: OSPFv2, Hello, length: 48
15:56:18.638299 IP 10.0.0.1 > 224.0.0.5: OSPFv2, Hello, length: 48
56 packets captured
112 packets received by filter
0 packets dropped by kernel
[root@london ~]#
and iptables:
[root@london ~]# iptables -t mangle -vnL POSTROUTING
Chain POSTROUTING (policy ACCEPT 1572K packets, 989M bytes)
pkts bytes target prot opt in out source
destination
0 0 mpls udp -- * * 10.0.0.1
10.0.0.10 udp spt:4001 dpt:4001 nhlfe 0xd
[root@london ~]#
So, we can see that te packet counters have not increased in iptables,
yet the packets are ''mapped'' on the nhlfe target.
I hope this helps.
Kind regards,
Tom
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X