I am trying to get OSPF working via OSPF and it looks like BIRD is ignoring OSPF packets coming in on the VRF interfaces. As far as I can tell from the documentation, I have all of the pieces in place, but the protocol is stuck in "Alone". The kernel version is 4.18.12, and I have the "vrf" parameter set on the kernel and ospf protocols. Here is my config: ipv4 table foo_ipv4; protocol kernel kernel_foo { vrf "foo"; kernel table 8194; learn; scan time 10; ipv4 { import all; export all; preference 1100; table foo_ipv4; }; } protocol direct direct_foo { vrf "foo"; ipv4 { table foo_ipv4; }; interface "foo"; interface "vl-foo"; interface "vx-foo"; } protocol ospf ospf_foo { vrf "foo"; router id 100.63.16.4; area 0.0.0.0 { interface "vl-foo"{ cost 10; }; interface "vx-foo" { cost 100; }; }; ipv4 { preference 1000; import all; export all; table foo_ipv4; }; } Here are my interfaces: 21: foo: <NOARP,MASTER,UP,LOWER_UP> mtu 65536 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 6a:f0:2c:ae:69:48 brd ff:ff:ff:ff:ff:ff promiscuity 0 vrf table 8194 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 22: vl-foo@host0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master foo state UP mode DEFAULT group default qlen 1000 link/ether 06:d8:07:73:68:b6 brd ff:ff:ff:ff:ff:ff promiscuity 0 vlan protocol 802.1Q id 2018 <REORDER_HDR> vrf_slave table 8194 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 23: vx-foo: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1432 qdisc noqueue master foo state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 32:08:91:57:b9:0b brd ff:ff:ff:ff:ff:ff promiscuity 0 vxlan id 2 srcport 0 0 dstport 4789 ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx vrf_slave table 8194 addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 If I debug the protocol, I only see it sending the HELLO packets:
ospf_foo: HELLO packet sent via vl-foo ospf_foo: HELLO packet sent via vx-foo ospf_foo: HELLO packet sent via vl-foo ospf_foo: HELLO packet sent via vl-foo ospf_foo: HELLO packet sent via vx-foo ospf_foo: HELLO packet sent via vl-foo ospf_foo: HELLO packet sent via vl-foo
However, I am seeing packets from the other router on the interface: # tcpdump -nei vl-foo proto 89 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vl-foo, link-type EN10MB (Ethernet), capture size 262144 bytes 08:17:22.583387 56:0f:a7:16:64:e2 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 82: 100.63.16.1 > 224.0.0.5: OSPFv2, Hello, length 48 08:17:28.364546 06:d8:07:73:68:b6 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 78: 192.168.1.5 > 224.0.0.5: OSPFv2, Hello, length 44 08:17:28.364682 06:d8:07:73:68:b6 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 78: 100.63.16.4 > 224.0.0.5: OSPFv2, Hello, length 44 08:17:32.583848 56:0f:a7:16:64:e2 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 82: 100.63.16.1 > 224.0.0.5: OSPFv2, Hello, length 48 08:17:38.364541 06:d8:07:73:68:b6 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 78: 100.63.16.4 > 224.0.0.5: OSPFv2, Hello, length 44 08:17:38.364645 06:d8:07:73:68:b6 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 78: 192.168.1.5 > 224.0.0.5: OSPFv2, Hello, length 44 Can anybody tell me what I am missing here? -- James Oakley james.oakley@multapplied.net
On Mon, Dec 03, 2018 at 04:20:50PM +0000, James Oakley wrote:
I am trying to get OSPF working via OSPF and it looks like BIRD is ignoring OSPF packets coming in on the VRF interfaces. As far as I can tell from the documentation, I have all of the pieces in place, but the protocol is stuck in "Alone". The kernel version is 4.18.12, and I have the "vrf" parameter set on the kernel and ospf protocols.
... However, I am seeing packets from the other router on the interface:
# tcpdump -nei vl-foo proto 89 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vl-foo, link-type EN10MB (Ethernet), capture size 262144 bytes 08:17:22.583387 56:0f:a7:16:64:e2 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 82: 100.63.16.1 > 224.0.0.5: OSPFv2, Hello, length 48 08:17:28.364546 06:d8:07:73:68:b6 > 01:00:5e:00:00:05, ethertype IPv4 (0x0800), length 78: 192.168.1.5 > 224.0.0.5: OSPFv2, Hello, length 44
Hi It is strange that you have such different source IP addresses. What is your IP range on vl-foo? What is reported by birdc commands 'show interfaces' and 'show ospf interface' ? Generally OSPFv2 interfaces are associated with one IP range, so alien packets are ignored. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On Monday, December 3, 2018 12:31 PM, Ondrej Zajicek wrote:
It is strange that you have such different source IP addresses. What is your IP range on vl-foo? What is reported by birdc commands 'show interfaces' and 'show ospf interface' ? Generally OSPFv2 interfaces are associated with one IP range, so alien packets are ignored.
I have 2 addresses on the interface in this case. vl-foo up (index=22 master=foo) MultiAccess Broadcast Multicast AdminUp LinkUp MTU=1500 100.63.16.4/21 (Preferred, scope univ) 192.168.1.5/24 (scope site) fe80::4d8:7ff:fe73:68b6/64 (Preferred, scope link) The idea is that the primary range, 100.x.x.x, is used for OSPF between nodes on the VLAN, and the secondary address is to emulate a legacy device, where the same address is needed on multiple VLANs. The secondary address isn't actually involved here, but I don't see a way in the documentation to limit it to only sending out with the primary address. -- James Oakley james.oakley@multapplied.net
participants (2)
-
James Oakley -
Ondrej Zajicek