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.

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

ipaddress on Linux - default route pointing to unaddressed interface, with route src #682

Merged

Conversation

glennmatthews
Copy link

Version: 8.5.1

Environment: Cisco IOS XR (Windriver Linux 7)

Scenario:

bash-4.3# ifconfig
Gi0_0_0_0 Link encap:Ethernet  HWaddr 52:46:0b:98:d2:51  
          inet addr:192.168.122.222  Mask:255.255.255.0
          inet6 addr: fe80::5046:bff:fe98:d251/64 Scope:Link
          UP RUNNING NOARP MULTICAST  MTU:1514  Metric:1
          RX packets:30965 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:45928110 (43.8 MiB)  TX bytes:210 (210.0 B)

Mg0_RP0_CPU0_0 Link encap:Ethernet  HWaddr 52:46:07:10:c6:14  
          inet addr:10.1.1.1  Mask:255.255.255.0
          inet6 addr: fe80::5046:7ff:fe10:c614/64 Scope:Link
          UP RUNNING NOARP MULTICAST  MTU:1514  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:210 (210.0 B)

fwd_ew    Link encap:Ethernet  HWaddr 00:00:00:00:00:0b  
          inet6 addr: fe80::200:ff:fe00:b/64 Scope:Link
          UP RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:1 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:140 (140.0 B)

fwdintf   Link encap:Ethernet  HWaddr 00:00:00:00:00:0a  
          inet6 addr: fe80::200:ff:fe00:a/64 Scope:Link
          UP RUNNING NOARP MULTICAST  MTU:1496  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8916 errors:0 dropped:1 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:631885 (617.0 KiB)

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:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo:0      Link encap:Local Loopback  
          inet addr:1.1.1.1  Mask:255.255.255.255
          UP LOOPBACK RUNNING  MTU:65536  Metric:1

lo:2      Link encap:Local Loopback  
          inet addr:2.2.2.2  Mask:255.255.255.255
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
bash-4.3# ip route show
default dev fwdintf  scope link  src 192.168.122.222 
10.1.1.0/24 dev Mg0_RP0_CPU0_0  proto kernel  scope link  src 10.1.1.1 

Expected Result:

ohai ipaddress should report 192.168.122.222 (the configured src for the default route) and ohai network should include "default_interface": "fwdintf"

Actual Result:

ohai ipaddress ignores the default route (because of existing logic that says 'ignore default route if its src is not an address configured on the default interface') and reports 1.1.1.1 (lowest global scope IP address found). No value is reported for default_interface.

Fix

If the default route src is not a configured address on the default interface, but the default interface has no addresses of this type, then do not ignore the default route when determining the ipaddress.

if route_entry[:src]
addr = iface[route_int][:addresses]
unless addr.nil? or addr.has_key? route_entry[:src] or
not addr.values.any? { |a| a['family'] == family[:name] }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use symbolic operators || and ! for boolean calculations.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry - I was following the convention of the existing code. Will rework my diffs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! =)

(I'll likely submit a rework of this code once your changes go through to remove the remaining instances.)

@glennmatthews
Copy link
Author

Changed to boolean operators as requested.

@glennmatthews
Copy link
Author

Hi, is anything needed to move this along?

@mcquin
Copy link
Contributor

mcquin commented Jan 19, 2016

Sorry for the delay @glennmatthews . It looks like there have been some recent changes to these files and we cannot cleanly merge. Would you please rebase this branch on latest master?

@glennmatthews
Copy link
Author

Yup looks like a conflict with the refactoring done by 58605b2. I'll see about getting it fixed.

@glennmatthews
Copy link
Author

@mcquin Rebased and reworked the diffs; tests are again passing. Thanks!

@thommay
Copy link
Contributor

thommay commented Jan 19, 2016

@btm you touched it last ;)

)
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this logic is kind of horrible to read. the comments are useful.

could we extract some helpers out of this though in order to make the logic more readable?

a trivial example:

def iface_has_no_addresses?(iface)
  iface[iface][:addresses].nil?
end

@glennmatthews
Copy link
Author

@lamont-granquist Sorry - were you asking me to refactor the code for readability? Or was that a general observation that this logic is quite messy (which I agree with, but predates my changes)?

@lamont-granquist
Copy link
Contributor

yeah refactoring the code for readability would be good.

@lamont-granquist
Copy link
Contributor

essentially, if you look where you have comments, if you could make the code read like the comments via helpers...

then the helpers become bite-size chunks that you can look at and validate that they do what it says on the tin. then you look at the overall algorithm and make sure it reads correctly...

@glennmatthews
Copy link
Author

OK, let me ask a different way - can this code be merged as-is, or will it not be accepted until I find the time to refactor it and resubmit? 😄

@lamont-granquist
Copy link
Contributor

yeah, i'd really like to see it more readable before accepting. otherwise i strongly suspect it won't get cleaned up, and then since this is the linux networking plugin, in 2-6 months after i've forgotten it, i'll have to waste a lot of time deciphering it when the next major PR comes in against it to fix some bug in the code...

@btm
Copy link
Contributor

btm commented Feb 9, 2016

@thom fwiw, I left it better than I got it. :)

I'll put this on the side of my desk and will help if it's still here when I find some time.

@glennmatthews
Copy link
Author

@adamleff will also be looking into the refactor later this week. Thanks Adam!

@adamleff
Copy link
Contributor

@mcquin / @lamont-granquist : would you mind giving this another look? I cleaned up #favored_default_route and think it's a whole bunch cleaner now. Also added tests for the new methods I added, and rebased against master.

/cc: @glennmatthews

@glennmatthews
Copy link
Author

👍 Nice work Adam!

@adamleff
Copy link
Contributor

Rebased on master again due to the conflict created by the chefstyle work yesterday. Should be good to go for another review, @mcquin and @lamont-granquist -- thank you!

)
)
# the route must have a source field
return false unless defined?(r[:src])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r[:src] will return nil if :src is not a key in the hash. It appears that defined?(nil) is truthy. Maybe you want unless r[:src].nil? or .empty?.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mcquin: That's a great find, because it actually uncovered an unrelated issue. The "returns" I was using was returning the whole method, not the individual #select eval block. When I implemented your fix, the tests uncovered unexpected results.

So thanks for that! I changed the logic and we should be good-to-go.

@mcquin
Copy link
Contributor

mcquin commented Feb 16, 2016

Code looks good to me. Thanks for the refactor @adamleff

@adamleff
Copy link
Contributor

@lamont-granquist if you get a chance today, can you take a peek at this and make sure it aligns with what you were thinking in terms of a refactor? thank you :)

Glenn Matthews and others added 4 commits February 18, 2016 13:56
- we have a default route to an interface
- the route has a configured src
- the src address is not configured on the default interface,
  but the default interface has no address at all

In this case we will choose the src as the ipaddress to report.
@lamont-granquist
Copy link
Contributor

yes, substantially more readable 👍

@lamont-granquist
Copy link
Contributor

@chef/client-core any moar eyeballs on this?

@thommay
Copy link
Contributor

thommay commented Feb 19, 2016

Looks like a great refactor, thanks! 👍

adamleff added a commit that referenced this pull request Feb 19, 2016
…rnercase

ipaddress on Linux - default route pointing to unaddressed interface, with route src
@adamleff adamleff merged commit a15a010 into chef:master Feb 19, 2016
@glennmatthews glennmatthews deleted the linux_network_ipaddress_cornercase branch February 19, 2016 14:42
@thommay thommay added Type: Bug Does not work as expected. and removed Bug labels Jan 24, 2017
@chef chef locked and limited conversation to collaborators Nov 16, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Type: Bug Does not work as expected.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants