Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ospfd: ospf_read network address is not same when using /32 IP #6823

Closed
liweitianux opened this issue Jul 30, 2020 · 8 comments · Fixed by #12115
Closed

ospfd: ospf_read network address is not same when using /32 IP #6823

liweitianux opened this issue Jul 30, 2020 · 8 comments · Fixed by #12115
Labels
triage Needs further investigation

Comments

@liweitianux
Copy link
Contributor

Describe the bug
A clear and concise description of what the bug is.

(put "x" in "[ ]" if you already tried following)
[x] Did you check if this is a duplicate issue?
[x] Did you test it on the latest FRRouting/frr master branch?

To Reproduce
Steps to reproduce the behavior:

  1. Configure an /32 IP (service/virtual IP for L3 ECMP load balancing) on an Ethernet interface (say eth2, the main WAN IP is also configured on this interface to communicate to the router)
  2. Configure a stub no-summary area for the interface eth2; the interface type is the default broadcast
  3. Start Zebra and OSPFd
  4. See the error OSPF: [EC 134217740] interface eth2:y.y.y.1: ospf_read network address is not same [x.x.x.1] in the log file.
  5. In vtysh show ip ospf neighbor, it's empty there.

Expected behavior

The OSPFd should build up adjacency with the router and function as expected.

Versions

  • OS Kernel: CentOS 7.4, 64-bit
  • FRR Version: commit fd2edd5 on master branch

Additional context

I'm coming into this issue in configuring our ECMP load balancing with OSPF in our datacenter. The OSPFd cannot build adjacency with the router with the following error message:

2020/07/30 17:32:36 OSPF: ospf_recv_packet: fd 14(default) on interface 8(eth2)
2020/07/30 17:32:36 OSPF: [EC 134217740] interface eth2:y.y.y.1: ospf_read network address is not same [x.x.x.1]
2020/07/30 17:32:36 OSPF: ospf_read[x.x.x.1]: Header check failed, dropping.

Basically, we need to configure on the same interface (e.g., eth2) a WAN IP (e.g., x.x.x.2/27, to contact with the router at x.x.x.1/27) and a bunch of service/virtual IPs with /32 subnet masks (e.g., y.y.y.1/32, y.y.y.2/32):

ospfd# show interface eth2 
Interface eth2 is up, line protocol is up
  Link ups:       0    last: (never)
  Link downs:     0    last: (never)
  vrf: default
  index 8 metric 0 mtu 1500 speed 10000 
  flags: <UP,BROADCAST,RUNNING,MULTICAST>
  Type: Ethernet
  HWaddr: 6c:92:bf:28:97:53
  inet x.x.x.2/27
  inet y.y.y.1/32 unnumbered
  inet6 fe80::6e92:bfff:fe28:9753/64
  Interface Type Other
  Interface Slave Type None

When the OSPFd receives a HELLO packet from the router, it need to lookup (ospf_if_lookup_recv_if() invocation in ospfd/ospf_packet.c) the OSPF interface before processing the packet. However, the unnumbered OSPF interface (i.e., y.y.y.1/32) is chosen (see ospf_if_lookup_recv_if() implementation), but it's not in the same network as the router. Therefore the packet header verification fails and thus causes the OSPF adjacency buildup fails.

I see the OSPF tutorial on Cumulus Linux that has a big note saying

Unnumbered is supported with point-to-point interfaces only.

So is this a bug in ospf_if_lookup_recv_if() or somewhere else?

I think this issue may be related to issue #3973 .

Thank you, and regards.
@liweitianux liweitianux added the triage Needs further investigation label Jul 30, 2020
@liweitianux
Copy link
Contributor Author

With the same OSPF setup (area, interface, and addresses), both Quagga (0.99.x version) and BIRD work fine on our CentOS 7 servers.

@Spantik
Copy link
Member

Spantik commented Aug 4, 2020

Hmmm this seems to be a issue. Code in FRR has been added such that it loops over the all ospf interface and then check in this order.

  1. Virtual link
  2. Unnumbered
    If any of these two matches then it breaks.

While quagga does not have this code. I think it is assumed that if we have a unnumbered interface then we should not be having broadcast.

This assumptions is broken with your config.

@rcmcdonald91
Copy link

whats the solution here?

@liweitianux
Copy link
Contributor Author

@theonemcdonald well, I don't know... But for us, we need to get OSPF working for our L4 load balance, so we've migrated to BIRD and it works well ;)

@astrablaster
Copy link

astrablaster commented Mar 15, 2022 •
edited
Loading

I'm suffering from the same issue.

My set up is: debian 11 in lxd (v4.23) container with FRR 8.1-0~deb11u1.
Hw node is running debian 11, kernel 5.10.0-11-amd64 and FRR 8.1-0~deb11u1.
It is working well on debian 8 in lxd container with quagga 0.99.23.1-1+deb8u5 (on the same hw node).

etc/networ/interfaces:
auto eth0
iface eth0 inet dhcp

auto eth0:0
iface eth0:0 inet static
    address 193.xxx.xxx.134/32


/etc/frr/ospfd.conf:
router ospf
    ospf router-id 193.xxx.xxx.134
    network 193.xxx.xxx.134/32 area 0
    network 10.100.0.0/16 area 0
    area 0 authentication message-digest

/etc/frr/zebra.conf
ip prefix-list any permit any
route-map set-source permit 10
 match ip address prefix-list any
 set src 193.xxx.xxx.134
ip protocol ospf route-map set-source

@mgob
Copy link

mgob commented Apr 13, 2022

This is an oldie but I'll toss my hat in the - this affects me too ring.

OPNsense 21.7.8-amd64
FreeBSD 12.1-RELEASE-p22-HBSD
FRR os-frr-1.26

I have a CARP on the same interface as the OSPF instance and I get the same error, removing the CARP /32 entry results in normal operation.

2022-04-13T08:44:54 ospfd[64790] [EC 134217741] interface lagg0_vlan2223:x.x.x.x: ospf_read network address is not same [10.1.0.49]  
2022-04-13T08:44:46 ospfd[64790] [EC 134217741] interface lagg0_vlan2223:x.x.x.x: ospf_read network address is not same [10.1.0.49]

@donaldsharp donaldsharp mentioned this issue Oct 12, 2022
Merged
@riw777 riw777 closed this as completed in 5136e67 Oct 13, 2022
mergify bot pushed a commit that referenced this issue Nov 8, 2022
@donaldsharp @mergify
ospfd: Allow unnumbered and numbered addresses to co-exist better
fe5434e 
When forming a neighbor relationship on an interface, ospf is
currently evaluating unnumbered as highest priority, without
any consideration for if you have /32's and non /32's on the
interface.  Effectively if I have something like this:

int foo0
  ip address 192.168.119.1/24
!
router ospf
  network 0.0.0.0/0 area 0
!

ospf will form a neighbor on foo0 if it exists.  Now
suppose someone does this:

int foo0
  ip address 192.168.120.1/32

This will create the unnumbered interface on foo0 and
the peering will come down immediately.

The problem here is that the original designers of the unnumbered
code for ospf didn't envision end operators mixing and matching
addresses on an interface like this ( for perfectly legitimate
reasons I might add ).

So if ospf has both numbered and unnumbered let's match against
the numbered first and then unnumbered.  This solves the problem

Fixes: #6823
Signed-off-by: Donald Sharp <[email protected]>
(cherry picked from commit 5136e67)
@KusakabeShi
Copy link

This issue happens again on latest frr

Jan 10 11:43:01 KSKB-IX-FRR ospfd[4205]: [EC 134217741] interface evpn-kskb-yi:192.168.23.1: ospf_read network address is not same [192.168.23.2]
Jan 10 11:43:11 KSKB-IX-FRR ospfd[4205]: [EC 134217741] interface evpn-kskb-yi:192.168.23.1: ospf_read network address is not same [192.168.23.2]
Jan 10 11:43:21 KSKB-IX-FRR ospfd[4205]: [EC 134217741] interface evpn-kskb-yi:192.168.23.1: ospf_read network address is not same [192.168.23.2]
Jan 10 11:43:31 KSKB-IX-FRR ospfd[4205]: [EC 134217741] interface evpn-kskb-yi:192.168.23.1: ospf_read network address is not same [192.168.23.2]
Jan 10 11:43:41 KSKB-IX-FRR ospfd[4205]: [EC 134217741] interface evpn-kskb-yi:192.168.23.1: ospf_read network address is not same [192.168.23.2]

@KusakabeShi
Copy link

Any plan to fix this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
triage Needs further investigation
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

ospfd: Allow unnumbered and numbered addresses to co-exist better donaldsharp/frr
6 participants
@liweitianux @rcmcdonald91 @mgob @astrablaster @Spantik @KusakabeShi