Oddities with connmark
Actually, there is a suricata with the following rules: #pass tls any any -> any any (pcre: "/play.google.com/i"; tls_sni;nfq_set_mark:0x8/0x; sid:2466;) #pass tls any any -> any any (pcre: "/google.com/i"; tls_sni;nfq_set_mark:0x8/0x; sid:2465;) #pass tls any any -> any any (pcre: "/gstatic.com/i"; tls_sni;nfq_set_mark:0x8/0x; sid:2467;) #pass tls any any -> any any (pcre: "/googleservice.com/i"; tls_sni;nfq_set_mark:0x8/0x; sid:2467;) pass tls any any -> any any (pcre: "/youtube.com/s"; tls_sni;nfq_set_mark:0x2/0x; sid:2455;) pass tls any any -> any any (pcre: "/googlevideo.com/s"; tls_sni;nfq_set_mark:0x2/0x; sid:2456;) pass http any any <> any any (content: "tactical-market.ru"; http_header;nfq_set_mark:0x4/0x; sid:2457;) pass http any any <> any any (content: "voent.org"; http_header;nfq_set_mark:0x4/0x; sid:2458;) pass http any any <> any any (content: "h-mag.ru"; http_header;nfq_set_mark:0x4/0x; sid:2459;) pass tls any any <> any any (content: "voent.org";tls_sni;nfq_set_mark:0x4/0x; sid:2460;) pass tls any any <> any any (content: "h-mag.ru";tls_sni;nfq_set_mark:0x4/0x; sid:2461;) rejectboth tcp any any <> any any (content: "GET http://";content: "Host: "; sid:2462;) pass http any any <> any any (content: "302";http_stat_code;content: "ivrn.net";http_header;nfq_set_mark:0x64/0x; sid:2463;) pass ssh any any <> any any (nfq_set_mark:0x6/0x; sid:2464;) #reject tls any any <> any any (content:"www.youtube.com"; tls_sni;nfq_set_mark:0x2/0x; sid:2456;) #ytimg.com iptables: Chain PREROUTING (policy ACCEPT 228K packets, 138M bytes) pkts bytes target prot opt in out source destination 11 3630 RETURN all -- * * 0.0.0.0 255.255.255.255 127K 121M RETURN all -- eth1 * 0.0.0.0/00.0.0.0/0 187 11489 RETURN all -- ppp0 * 0.0.0.0/00.0.0.0/0 10365 2323K RETURN all -- vpns0.10 * 0.0.0.0/00.0.0.0/0 0 0 LOGall -- * * 0.0.0.0/00.0.0.0/0 rpfilter invert LOG flags 0 level 4 prefix "IP SPOOFING: " 0 0 DROP all -- * * 0.0.0.0/00.0.0.0/0 rpfilter invert 0 0 DROP all -- * * 0.0.0.0/00.0.0.0/0 -m ipv4options --flags 7 0 0 DROP all -- * * 0.0.0.0/00.0.0.0/0 -m ipv4options --flags 3 0 0 DROP all -- * * 0.0.0.0/00.0.0.0/0 -m ipv4options --flags 9 0 0 MARK all -- * * 0.0.0.0/00.0.0.0/0 match-set dpi_detect dst MARK xset 0x40/0xfe 0 0 MARK all -- * * 0.0.0.0/00.0.0.0/0 match-set dpi_detect src MARK xset 0x40/0xfe Chain INPUT (policy ACCEPT 107K packets, 45M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 120K packets, 93M bytes) pkts bytes target prot opt in out source destination 241K 185M DPIall -- * * 0.0.0.0/00.0.0.0/0 120K 93M DPI_SH all -- * * 0.0.0.0/00.0.0.0/0 2063 123K TCPMSS tcp -- * * 0.0.0.0/00.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU Chain OUTPUT (policy ACCEPT 109K packets, 24M bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 229K packets, 116M bytes) pkts bytes target prot opt in out source destination Chain DPI (1 references) pkts bytes target prot opt in out source destination 0 0 RETURN all -- * * 198.18.0.0/15 192.168.0.0/15 0 0 RETURN all -- * * 192.168.0.0/16 198.18.0.0/15 0 0 RETURN all -- * * 192.168.0.0/16 192.168.0.0/16 121K 93M NFQUEUEall -- * * 0.0.0.0/00.0.0.0/0 mark match ! 0x1/0x1 NFQUEUE num 0 Chain DPI_SH (1 references) pkts bytes target prot opt in out source destination 3542 2688K RETURN all -- * * 0.0.0.0/00.0.0.0/0 connmark match 0x8/0xfe 53 45450 CONNMARK all -- * * 0.0.0.0/00.0.0.0/0 mark match 0x8/0xfe CONNMARK xset 0x8/0xfe 0 0 CONNMARK all -- * * 0.0.0.0/00.0.0.0/0 mark match 0x4/0xfe CONNMARK xset 0x4/0xfe 8 9366 CONNMARK all -- * * 0.0.0.0/00.0.0.0/0
Packet corrupts to guest system system from host kernel 4.16.x
Why, when using the 4.16 kernel on the host system, is there such a strange behavior of virtual machines? What is the problem? He rolled back to 4.9.c - the problem was gone. tcpdump on router: tcpdump: listening on vlan-00110013, link-type EN10MB (Ethernet), capture size 262144 bytes 23:59:08.331875 52:54:00:38:cf:94 > 52:54:00:4e:9c:5f, ethertype ARP (0x0806), length 38: [|ARP] 0x: 0001 0800 0604 0001 5254 0038 cf94 c0a8 RT.8 0x0010: b402 23:59:08.454364 52:54:00:4e:9c:5f > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.180.2 tell 192.168.180.1, length 28 23:59:08.454754 52:54:00:38:cf:94 > 52:54:00:4e:9c:5f, ethertype ARP (0x0806), length 38: [|ARP] 0x: 0001 0800 0604 0002 5254 0038 cf94 c0a8 RT.8 0x0010: b402 5254 004e 9c5f ..RT.N._ 23:59:09.462383 52:54:00:4e:9c:5f > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.180.2 tell 192.168.180.1, length 28 23:59:09.463607 52:54:00:38:cf:94 > 52:54:00:4e:9c:5f, ethertype ARP (0x0806), length 38: [|ARP] 0x: 0001 0800 0604 0002 5254 0038 cf94 c0a8 RT.8 0x0010: b402 5254 004e 9c5f ..RT.N._ 23:59:10.486352 52:54:00:4e:9c:5f > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.180.2 tell 192.168.180.1, length 28 23:59:10.487303 52:54:00:38:cf:94 > 52:54:00:4e:9c:5f, ethertype ARP (0x0806), length 38: [|ARP] 0x: 0001 0800 0604 0002 5254 0038 cf94 c0a8 RT.8 0x0010: b402 5254 004e 9c5f ..RT.N._ 23:59:11.051570 52:54:00:38:cf:94 > 52:54:00:4e:9c:5f, ethertype IPv4 (0x0800), length 77: truncated-ip - 4 bytes missing! (tos 0x0, ttl 64, id 54539, offset 0, flags [DF], proto UDP (17), length 67) 192.168.180.2.59917 > 198.18.120.1.53: 1196+[|domain] 23:59:11.051585 52:54:00:38:cf:94 > 52:54:00:4e:9c:5f, ethertype IPv4 (0x0800), length 77: truncated-ip - 4 bytes missing! (tos 0x0, ttl 64, id 54540, offset 0, flags [DF], proto UDP (17), length 67) 192.168.180.2.59917 > 198.18.120.1.53: 5849+[|domain] 23:59:11.527109 52:54:00:4e:9c:5f > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.180.2 tell 192.168.180.1, length 28 23:59:11.527707 52:54:00:38:cf:94 > 52:54:00:4e:9c:5f, ethertype ARP (0x0806), length 38: [|ARP] 0x: 0001 0800 0604 0002 5254 0038 cf94 c0a8 RT.8 0x0010: b402 5254 004e 9c5f ..RT.N._ ^C 11 packets captured 11 packets received by filter 0 packets dropped by kernel
MPLS-TP From Linux
Please tell me if the MPLS-TP implementation in Linux is being implemented? RFC: https://tools.ietf.org/html/rfc5654
Multicast MPLS is Linux
Tell me please, when in linux is planned the realization of multicast MPLS? Etnernet Tipe: 0c8848
Module compile error
CC [M] drivers/net/ethernet/intel/ixgbe/ixgbe_main.o In file included from ./include/net/vxlan.h:6:0, from drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:60: ./include/net/dst_metadata.h: In function ‘skb_vpls_info’: ./include/net/dst_metadata.h:36:9: error: implicit declaration of function ‘skb_metadata_dst’ [-Werror=implicit-function-declaration] struct metadata_dst *md_dst = skb_metadata_dst(skb); ^ ./include/net/dst_metadata.h:36:32: warning: initialization makes pointer from integer without a cast struct metadata_dst *md_dst = skb_metadata_dst(skb); ^ ./include/net/dst_metadata.h: At top level: ./include/net/dst_metadata.h:42:36: error: conflicting types for ‘skb_metadata_dst’ static inline struct metadata_dst *skb_metadata_dst(struct sk_buff *skb) ^ ./include/net/dst_metadata.h:36:32: note: previous implicit declaration of ‘skb_metadata_dst’ was here struct metadata_dst *md_dst = skb_metadata_dst(skb); ^ cc1: some warnings being treated as errors scripts/Makefile.build:302: recipe for target 'drivers/net/ethernet/intel/ixgbe/ixgbe_main.o' failed make[5]: *** [drivers/net/ethernet/intel/ixgbe/ixgbe_main.o] Error 1 scripts/Makefile.build:561: recipe for target 'drivers/net/ethernet/intel/ixgbe' failed make[4]: *** [drivers/net/ethernet/intel/ixgbe] Error 2 scripts/Makefile.build:561: recipe for target 'drivers/net/ethernet/intel' failed make[3]: *** [drivers/net/ethernet/intel] Error 2 scripts/Makefile.build:561: recipe for target 'drivers/net/ethernet' failed make[2]: *** [drivers/net/ethernet] Error 2 scripts/Makefile.build:561: recipe for target 'drivers/net' failed make[1]: *** [drivers/net] Error 2 Makefile:1019: recipe for target 'drivers' failed make: *** [drivers] Error 2 This patch is https://github.com/eqvinox/vpls-linux-kernel/commit/d9d8efec0760bcea54496e7a3ed45c72316ffb6b#diff-00c78c934b7e227c38ff1b1b571db9e6 What could be the problem? Kernel: 4.13.16
David Lamparter
And what happened to him?
VPLS Support
Hello, when will VPLS be implemented in Linux? August 15, 2017 were patches from ekoinoks, which in Linux added support for VPLS. But, these patches for some reason did not pass. Also, for some reason, the author of these patches has no activity on, for two months. I think so, if activity does not appear in the near future, I will have to take his patches and send it back to the kernel.
VPLS in Linux
When will support for VPLS appear in Linux? 08/21/2017 David Lamparter has already sent these patches, but they are not in the kernel for some reason, not populi. Such question, when all the same these patches will get to a kernel? Here is a link to this email: https://www.mail-archive.com/netdev@vger.kernel.org/msg184110.html
VPLS in Linux
There was a message with patches of VPLS in the Linux kernel. But they somehow did not fall into the next. What about the development of the Linux subsystem in Linux?
https://www.spinics.net/lists/kernel/ non work
Forbidden You don't have permission to access /lists/kernel/ on this server. Apache/2.4.6 (CentOS) Server at www.spinics.net Port 443
iproute2 invalid argument mpls labels
I updated the kernel 4.12.6. When the mote is hung on the route more than 8 mpls of marks through iproute2, I get the following: root@ne-vlezay80:~# ip route add 10.10.10.0/24 encap mpls 50/60/70/80/90/100/110/120/130 dev lo RTNETLINK answers: Invalid argument root@ne-vlezay80:~# ip route add 10.10.10.0/24 encap mpls 50/60/70/80/90/100/110/120 dev lo root@ne-vlezay80:~# root@ne-vlezay80:~# ip r default via 10.247.0.1 dev ic-br0 proto zebra metric 20 10.10.10.0/24 encap mpls ///120 dev lo scope link root@ne-vlezay80:~# cat /usr/src/linux-4.12.6/net/mpls/internal.h|grep MAX_NEW #define MAX_NEW_LABELS 30 root@ne-vlezay80:~# What is the problem, and how can more than 8 MPLS markers be hung on through iproute2? root@ne-vlezay80:~# uname -r 4.12.6 root@ne-vlezay80:~#
Linux MPLS traceroute failure
Testing MPLS from Linux kernel 4.12. The trace route is duplicete pe-p hop. This is not visible MPLS label on traceroute. root@ne-vlezay80:~# traceroute -e 10.10.10.4 traceroute to 10.10.10.4 (10.10.10.4), 30 hops max, 60 byte packets 1 10.5.5.1 (10.5.5.1) 0.028 ms 0.005 ms 0.006 ms 2 10.4.4.2 (10.4.4.2) 0.021 ms 0.007 ms 0.012 ms 3 10.4.4.2 (10.4.4.2) 0.008 ms 0.008 ms 0.007 ms 4 10.10.10.4 (10.10.10.4) 0.015 ms 0.009 ms 0.008 ms root@ne-vlezay80:~#
Re: MPLS Pseudowire (RFC3985) linux kernel support and development
As I understand it, the patch will be available in the linux kernel or as a separate application based on tap? 06.07.2017, 16:21, "Vincent JARDIN" : > Le 06/07/2017 à 11:13, Алексей Болдырев a écrit : >> Is there any plan for developing mpls pseudowire dliver for linux. And >> also, is it possible to write a driver for MPLS pseudowire on the basis of >> tun / tap? > > We are working on a RFC patch that should be available soon. > They'll be tested with FRR. > > best regards,
MPLS Pseudowire (RFC3985) linux kernel support and development
Is there any plan for developing mpls pseudowire dliver for linux. And also, is it possible to write a driver for MPLS pseudowire on the basis of tun / tap?
veth: проблемы со скоростью
Короче, имеем ядро 4.11.4. При передаче данных через veth, мы получаем скорость примерно такую: root@containers:~# iperf3 -c 10.194.1.3 Connecting to host 10.194.1.3, port 5201 [ 4] local 10.194.1.2 port 55640 connected to 10.194.1.3 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 678 MBytes 5.68 Gbits/sec0 1.10 MBytes [ 4] 1.00-2.00 sec 684 MBytes 5.73 Gbits/sec0 1.60 MBytes [ 4] 2.00-3.00 sec 684 MBytes 5.74 Gbits/sec0 1.60 MBytes [ 4] 3.00-4.00 sec 686 MBytes 5.75 Gbits/sec0 1.60 MBytes [ 4] 4.00-5.00 sec 685 MBytes 5.75 Gbits/sec0 1.60 MBytes [ 4] 5.00-6.00 sec 684 MBytes 5.73 Gbits/sec0 1.60 MBytes [ 4] 6.00-7.00 sec 684 MBytes 5.74 Gbits/sec0 1.60 MBytes [ 4] 7.00-8.00 sec 684 MBytes 5.74 Gbits/sec0 1.60 MBytes [ 4] 8.00-9.00 sec 686 MBytes 5.75 Gbits/sec0 1.60 MBytes [ 4] 9.00-10.00 sec 685 MBytes 5.75 Gbits/sec0 1.60 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 6.68 GBytes 5.74 Gbits/sec0 sender [ 4] 0.00-10.00 sec 6.68 GBytes 5.74 Gbits/sec receiver iperf Done. Собственно, в чём вопрос: Какие изменения были внесины в драйвер veth? На сколько я понимаю, маленькая скорость возникает потому, что включенна проверка от плохих пакетов, которые были в этом баге: https://github.com/kubernetes/kubernetes/issues/18898 Дело в том, что veth используется также для создания псевдо туннелей, например если надо покключить в l2 режиме устройства которые не поддерживают больших пакетов к сети, в которой есть jumbo frame. Дело в том, что эту проверку невозможно отключить.
BUG: Bad page state in process Compositor pfn:c03e2
[ 1621.875870] BUG: Bad page state in process Compositor pfn:c03e2 [ 1621.875876] page:ea000300f880 count:-1 mapcount:0 mapping: (null) index:0x0 [ 1621.875878] flags: 0x100() [ 1621.875881] raw: 0100 [ 1621.875882] raw: dead0200 [ 1621.875883] page dumped because: nonzero _count [ 1621.875884] Modules linked in: vhost_net vhost tap af_packet tun ebtable_filter ebtables x_tables dummy nbd bridge 8021q garp mrp stp llc ata_generic pata_acpi snd_hda_codec_realtek snd_hda_codec_generic snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev media snd_hda_intel snd_hda_codec snd_pcsp snd_hda_core snd_hwdep kvm_amd snd_pcm kvm snd_timer snd irqbypass e1000 soundcore pata_atiixp nouveau r8169 ttm tpm_infineon mii wmi acpi_cpufreq ohci_pci tpm_tis ohci_hcd tpm_tis_core tpm fuse ipv6 crc_ccitt unix [ 1621.875907] CPU: 0 PID: 3674 Comm: Compositor Not tainted 4.11.3 #2 [ 1621.875907] Hardware name: MSI MS-7715/870-C45(FX) V2 (MS-7715) , BIOS V3.1 04/16/2012 [ 1621.875908] Call Trace: [ 1621.875914] dump_stack+0x4d/0x65 [ 1621.875916] bad_page+0xc1/0x130 [ 1621.875917] check_new_page_bad+0x75/0x80 [ 1621.875918] get_page_from_freelist+0x6fd/0xab0 [ 1621.875920] ? enqueue_task_fair+0xfa5/0x1910 [ 1621.875921] ? select_task_rq_fair+0xaeb/0xed0 [ 1621.875923] __alloc_pages_nodemask+0xcb/0x200 [ 1621.875924] alloc_pages_current+0x8d/0x110 [ 1621.875926] alloc_skb_with_frags+0xcb/0x1c0 [ 1621.875928] sock_alloc_send_pskb+0x1e4/0x210 [ 1621.875931] unix_stream_sendmsg+0x26c/0x3b0 [unix] [ 1621.875932] sock_sendmsg+0x33/0x40 [ 1621.875933] sock_write_iter+0x76/0xd0 [ 1621.875935] __do_readv_writev+0x29e/0x370 [ 1621.875936] do_readv_writev+0x78/0xa0 [ 1621.875937] vfs_writev+0x37/0x50 [ 1621.875939] ? __fdget_pos+0x12/0x50 [ 1621.875940] ? vfs_writev+0x37/0x50 [ 1621.875940] do_writev+0x4d/0xd0 [ 1621.875942] SyS_writev+0xb/0x10 [ 1621.875943] entry_SYSCALL_64_fastpath+0x13/0x94 [ 1621.875944] RIP: 0033:0x7f730f8dd2f0 [ 1621.875945] RSP: 002b:7f72f15f55f0 EFLAGS: 0293 ORIG_RAX: 0014 [ 1621.875946] RAX: ffda RBX: 7f72cc39cf28 RCX: 7f730f8dd2f0 [ 1621.875947] RDX: 0003 RSI: 7f72f15f5790 RDI: 0004 [ 1621.875947] RBP: 7f72c7ee1c00 R08: R09: [ 1621.875948] R10: 0020 R11: 0293 R12: 7f72f15f6e01 [ 1621.875948] R13: R14: 0166 R15: 7f72cc39d428 [ 1621.875949] Disabling lock debugging due to kernel taint
Re: Maximum MPLS labels on Linux network stack
As I understand it, it's enough to just set the variable in the source #define FLOW_MAX_MPLS_LABELS 3 on #define FLOW_MAX_MPLS_LABELS 7 Or is there somehow still pitfalls? 04.05.2017, 00:22, "Joe Stringer" : > On 3 May 2017 at 14:19, Алексей Болдырев > wrote: >> Is it possible to increase this limit in OpenVswitch? > > Yes.
Re: Maximum MPLS labels on Linux network stack
Is it possible to increase this limit in OpenVswitch? 03.05.2017, 23:21, "Joe Stringer" : > On 3 May 2017 at 11:14, David Ahern wrote: >> On 5/3/17 11:33 AM, Алексей Болдырев wrote: >>> I watched one forum, there is listed in the properties of one license for >>> Cisco, it says: >>> >>> Layer 3 VPN • Multi-VRF CE (VRF-lite); requires IP Services Feature license >>> • MPLS VPN; requires Advanced IP Feature license >>> • 26 VRFs >> >> There is no direct limit on the number of VRFs the kernel allows you to >> create. There are indirect ones -- total memory in the system and limits >> such as /proc/sys/net/ipv6/route/max_size. By increasing the latter I >> have created 4k VRFs in a system. >> >>> • 8192 MPLS labels >>> >>> Especially interested in the figure 8192 MPLS Labels. >> >> 8192 labels added in one pass is absurd. There is no reason to support >> such a number. With the latest version of the MPLS stack in the kernel >> you can add up to 30 labels in a single route. If you want more you have >> to either recirculate the packet using routes or recompile the kernel >> and increase the memory limit and the number of labels limit. >> >>> As I understand it, is it either a limit on the number of labels on the >>> stack or the total number of labels? >>> >>> In Linux, for example, you can specify a common col- lection of labels >>> through /proc/sys/net/mpls/platforms_labels >> >> that just allocates the size of an array which dictates the max label >> number for that namespace. The array needs to be converted to a hash >> table at some point. >> >>> Also I would like to know if the openvswitch has a limit of 3 tags in the >>> stack or the total number of MPLS labels that can send? >> >> someone familiar with OVS needs to answer that. > > That would be 3 tags in a stack. When we spoke to people involved in > the design and usage of MPLS in practice, we got the impression that > it's very rare for anyone to configure a setup where more than that is > used concurrently on a packet. If you believe the contrary, then I > imagine it's not hard to bump that limit. > > There is no limit on which labels can be used from OVS, it's just a > number in an action attached to a flow.
Maximum MPLS labels on Linux network stack
I watched one forum, there is listed in the properties of one license for Cisco, it says: Layer 3 VPN • Multi-VRF CE (VRF-lite); requires IP Services Feature license • MPLS VPN; requires Advanced IP Feature license • 26 VRFs • 8192 MPLS labels Especially interested in the figure 8192 MPLS Labels. As I understand it, is it either a limit on the number of labels on the stack or the total number of labels? In Linux, for example, you can specify a common col- lection of labels through /proc/sys/net/mpls/platforms_labels Also I would like to know if the openvswitch has a limit of 3 tags in the stack or the total number of MPLS labels that can send?
Low speed MPLS to virtio-net
Started MPLS on the branch - Everything was fine. When I tried to run MPLS on a real network of virtual machines, there were problems with the speed: root@containers:~# iperf3 -c 10.194.10.2 -B 10.194.10.1 -Z Connecting to host 10.194.10.2, port 5201 [ 4] local 10.194.10.1 port 49533 connected to 10.194.10.2 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 1018 KBytes 8.34 Mbits/sec 238 5.64 KBytes [ 4] 1.00-2.00 sec 1.42 MBytes 11.9 Mbits/sec 373 1.41 KBytes [ 4] 2.00-3.00 sec 1.43 MBytes 12.0 Mbits/sec 379 5.64 KBytes [ 4] 3.00-4.00 sec 1.43 MBytes 12.0 Mbits/sec 376 5.64 KBytes [ 4] 4.00-5.00 sec 1.41 MBytes 11.8 Mbits/sec 375 2.82 KBytes [ 4] 5.00-6.00 sec 1.42 MBytes 11.9 Mbits/sec 376 2.82 KBytes [ 4] 6.00-7.00 sec 1.42 MBytes 11.9 Mbits/sec 373 5.64 KBytes [ 4] 7.00-8.00 sec 1.41 MBytes 11.8 Mbits/sec 372 5.64 KBytes [ 4] 8.00-9.00 sec 1.42 MBytes 11.9 Mbits/sec 379 2.82 KBytes [ 4] 9.00-10.00 sec 1.42 MBytes 11.9 Mbits/sec 373 5.64 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 13.8 MBytes 11.5 Mbits/sec 3614 sender [ 4] 0.00-10.00 sec 13.6 MBytes 11.4 Mbits/sec receiver iperf Done. root@containers:~# Here are the settings: test0: lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo:1: flags=73 mtu 65536 inet 10.194.10.1 netmask 255.255.255.255 loop txqueuelen 1000 (Local Loopback) test0p1: flags=4163 mtu 1500 inet 10.194.1.50 netmask 255.255.255.0 broadcast 10.194.1.255 inet6 fe80::b0a7:b1ff:fec1:3d5c prefixlen 64 scopeid 0x20 ether b2:a7:b1:c1:3d:5c txqueuelen 1000 (Ethernet) RX packets 19974 bytes 1410944 (1.3 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 3726844 bytes 5236310466 (4.8 GiB) TX errors 0 dropped 3604 overruns 0 carrier 0 collisions 0 test1: lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1000 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo:1: flags=73 mtu 65536 inet 10.194.10.2 netmask 255.255.255.255 loop txqueuelen 1000 (Local Loopback) test1p1: flags=4163 mtu 1500 inet 10.194.1.51 netmask 255.255.255.0 broadcast 10.194.1.255 inet6 fe80::5cc0:45ff:fe1a:9705 prefixlen 64 scopeid 0x20 ether 5e:c0:45:1a:97:05 txqueuelen 1000 (Ethernet) RX packets 2001923 bytes 2806406771 (2.6 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 19907 bytes 1485150 (1.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Server configuration: root@ne-vlezay80:~# ip -M r 100 via inet 10.194.1.50 dev vlan11 101 via inet 10.194.1.51 dev vlan11 root@ne-vlezay80:~# root@ne-vlezay80:~# ifconfig eth0 Link encap:Ethernet HWaddr 52:54:00:5d:81:90 inet addr:10.247.0.250 Bcast:10.247.0.255 Mask:255.255.255.0 inet6 addr: fe80::5054:ff:fe5d:8190/64 Scope:Link inet6 addr: fd00:1002:1289:10::10/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:2500 Metric:1 RX packets:7403 errors:0 dropped:0 overruns:0 frame:0 TX packets:4182 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:621871 (607.2 KiB) TX bytes:445766 (435.3 KiB) eth1 Link encap:Ethernet HWaddr 52:54:00:0b:ff:2e inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 inet6 addr: fd00:104:1::1/64 Scope:Global inet6 addr: fe80::5054:ff:fe0b:ff2e/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:2500 Metric:1 RX packets:2204837 errors:0 dropped:5 overruns:0 frame:0 TX packets:2083636 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3073876412 (2.8 GiB) TX bytes:2897017540 (2.6 GiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:75 errors:0 dropped:0 overruns:0 frame:0 TX packets:75 errors:0 dropped:0 overruns:0 carrier:0 collisio
Re: Bug and configuration MPLS error?
26.04.2017, 05:23, "David Ahern" : > On 4/25/17 11:28 AM, Алексей Болдырев wrote: >> 226 sysctl -w net.mpls.conf.lo.input=1 >> 227 sysctl -w net.mpls.platform_labels=1048575 >> 228 ip link add veth0 type veth peer name veth1 >> 229 ip link add veth2 type veth peer name veth3 >> 230 sysctl -w net.mpls.conf.veth0.input=1 >> 231 sysctl -w net.mpls.conf.veth2.input=1 >> 232 ifconfig veth0 10.3.3.1 netmask 255.255.255.0 >> 233 ifconfig veth2 10.4.4.1 netmask 255.255.255.0 >> 234 ip netns add host1 >> 235 ip netns add host2 >> 236 ip link set veth1 netns host1 >> 237 ip link set veth3 netns host2 >> 238 ip netns exec host1 ifconfig veth1 10.3.3.2 netmask 255.255.255.0 up >> 239 ip netns exec host2 ifconfig veth3 10.4.4.2 netmask 255.255.255.0 up >> 240 ip netns exec host1 ip route add 10.10.10.2/32 encap mpls 112 via inet >> 10.3.3.1 >> 241 ip netns exec host2 ip route add 10.10.10.1/32 encap mpls 111 via inet >> 10.4.4.1 >> 242 ip -f mpls route add 111 via inet 10.3.3.2 >> 243 ip -f mpls route add 112 via inet 10.4.4.2 > > your setup is incomplete. > > # ip netns exec host2 ping 10.10.10.1 > PING 10.10.10.1 (10.10.10.1) 56(84) bytes of data. > ^C > --- 10.10.10.1 ping statistics --- > 2 packets transmitted, 0 received, 100% packet loss, time 1038ms > > If you run tcpdump on veth1 in host1 you see the packets come in but no > response: > > # ip netns exec host1 tcpdump -n -i veth1 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on veth1, link-type EN10MB (Ethernet), capture size 262144 bytes > 19:20:24.599529 IP6 fe80::347d:e3ff:fe93:944b > ff02::2: ICMP6, router > solicitation, length 16 > 19:20:27.413901 IP 10.4.4.2 > 10.10.10.1: ICMP echo request, id 978, seq > 1, length 64 > 19:20:28.439574 IP 10.4.4.2 > 10.10.10.1: ICMP echo request, id 978, seq > 2, length 64 > > and the lack of response is b/c: > 1. host1 has no address for 10.10.10.1 and > 2. even if it did, there is no return route to 10.4.4.2: > > # ip -netns host1 ro ls > 10.3.3.0/24 dev veth1 proto kernel scope link src 10.3.3.2 > 10.10.10.2 encap mpls 112 via 10.3.3.1 dev veth1 As for ping, you need to enter this: Ip netns exec host2 ping 10.10.10.1 -A 10.10.10.2 Here I published the results of testing on new (>4.9) cores. (in Russian): http://forum.nag.ru/forum/index.php?s=d09f0e5186fda59b3099eb81ad07ee63&showtopic=128927 But on the old kernels: http://forum.nag.ru/forum/index.php?showtopic=128927&view=findpost&p=1396067
Bug and configuration MPLS error?
Короче, вот конфиг MPLS на одном из дистрибутивов: In short, here's the MPLS configuration on one of the distributions: 226 sysctl -w net.mpls.conf.lo.input=1 227 sysctl -w net.mpls.platform_labels=1048575 228 ip link add veth0 type veth peer name veth1 229 ip link add veth2 type veth peer name veth3 230 sysctl -w net.mpls.conf.veth0.input=1 231 sysctl -w net.mpls.conf.veth2.input=1 232 ifconfig veth0 10.3.3.1 netmask 255.255.255.0 233 ifconfig veth2 10.4.4.1 netmask 255.255.255.0 234 ip netns add host1 235 ip netns add host2 236 ip link set veth1 netns host1 237 ip link set veth3 netns host2 238 ip netns exec host1 ifconfig veth1 10.3.3.2 netmask 255.255.255.0 up 239 ip netns exec host2 ifconfig veth3 10.4.4.2 netmask 255.255.255.0 up 240 ip netns exec host1 ip route add 10.10.10.2/32 encap mpls 112 via inet 10.3.3.1 241 ip netns exec host2 ip route add 10.10.10.1/32 encap mpls 111 via inet 10.4.4.1 242 ip -f mpls route add 111 via inet 10.3.3.2 243 ip -f mpls route add 112 via inet 10.4.4.2 Результаты теста: Test Results: tcp по mpls: ~ # ip netns exec host2 iperf3 -c 10.10.10.1 -B 10.10.10.2 Connecting to host 10.10.10.1, port 5201 [ 4] local 10.10.10.2 port 34021 connected to 10.10.10.1 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 912 KBytes 7.46 Mbits/sec 0 636 KBytes [ 4] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes [ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes [ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes [ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes [ 4] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes [ 4] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes [ 4] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes [ 4] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 0 636 KBytes [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 912 KBytes 747 Kbits/sec 0 sender [ 4] 0.00-10.00 sec 21.3 KBytes 17.5 Kbits/sec receiver iperf Done. ~ # udp по mpls: ~ # ip netns exec host2 iperf3 -c 10.10.10.1 -B 10.10.10.2 -u -b 10g Connecting to host 10.10.10.1, port 5201 [ 4] local 10.10.10.2 port 56901 connected to 10.10.10.1 port 5201 [ ID] Interval Transfer Bandwidth Total Datagrams [ 4] 0.00-1.00 sec 438 MBytes 3.67 Gbits/sec 56049 [ 4] 1.00-2.00 sec 491 MBytes 4.12 Gbits/sec 62829 [ 4] 2.00-3.00 sec 492 MBytes 4.12 Gbits/sec 62919 [ 4] 3.00-4.00 sec 490 MBytes 4.11 Gbits/sec 62762 [ 4] 4.00-5.00 sec 491 MBytes 4.12 Gbits/sec 62891 [ 4] 5.00-6.00 sec 492 MBytes 4.13 Gbits/sec 62994 [ 4] 6.00-7.00 sec 503 MBytes 4.22 Gbits/sec 64322 [ 4] 7.00-8.00 sec 503 MBytes 4.22 Gbits/sec 64321 [ 4] 8.00-9.00 sec 502 MBytes 4.21 Gbits/sec 64279 [ 4] 9.00-10.00 sec 511 MBytes 4.28 Gbits/sec 65352 [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.00-10.00 sec 4.80 GBytes 4.12 Gbits/sec 0.001 ms 0/628718 (0%) [ 4] Sent 628718 datagrams iperf Done. UDP как видим, проходит нормально. UDP as seen, is normal. Вот параметры интерфейсов: Here are the interface parameters: P: veth0 Link encap:Ethernet HWaddr 72:0D:9E:D7:BC:B3 inet addr:10.3.3.1 Bcast:10.3.3.255 Mask:255.255.255.0 inet6 addr: fe80::700d:9eff:fed7:bcb3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:65535 Metric:1 RX packets:126 errors:0 dropped:0 overruns:0 frame:0 TX packets:629026 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:9592 (9.3 KiB) TX bytes:5178498619 (4.8 GiB) veth2 Link encap:Ethernet HWaddr CE:24:F8:1F:99:C1 inet addr:10.4.4.1 Bcast:10.4.4.255 Mask:255.255.255.0 inet6 addr: fe80::cc24:f8ff:fe1f:99c1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:65535 Metric:1 RX packets:629015 errors:0 dropped:0 overruns:0 frame:0 TX packets:135 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:5181014123 (4.8 GiB) TX bytes:9564 (9.3 KiB) PE1: ~ # ip netns exec host2 ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) veth3 Link encap:Ethernet HWaddr 36:00:C2:29:0D:F9 inet addr:10.4.4.2 Bcast:10.4.4.255 Mask:255.255.255.0 inet6 addr: fe80::3400:c2ff:fe29:df9/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:65200 Metric:1 RX packets:136 errors:0 dropped:0 overruns:0 frame:0 TX packets:629015 errors:0 dropped:1 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:9596 (9.3 KiB) TX bytes:5181014123 (4.8 GiB) PE2: lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) veth1 Li
