Skip to content
This repository has been archived by the owner on Apr 4, 2024. It is now read-only.

vnet and ip don't like eachother #78

Closed
Licenser opened this issue Mar 21, 2017 · 10 comments
Closed

vnet and ip don't like eachother #78

Licenser opened this issue Mar 21, 2017 · 10 comments

Comments

@Licenser
Copy link
Contributor

Setting up a jail with vnet & a ip doesn't seem to work well together. It is however documented to work: http://iocage.readthedocs.io/en/latest/networking.html#vimage-vnet

root@fifo-bsd:~ # iocage set ip4_addr="vnet0|192.168.1.210/24" 051999d0
Property: ip4_addr has been updated to vnet0|192.168.1.210/24
ERROR: jail: vnet jails cannot have IP address restrictions
@skarekrow
Copy link
Member

Try dropping /24 as that should be /32 afaik anyways :P

@Licenser
Copy link
Contributor Author

Hope, no luck. Also isn't the /24 the netmaks (aka 192.168.1.210 mask 255.255.255.0)

@skarekrow
Copy link
Member

skarekrow commented Mar 21, 2017

Hmm. I normally don't specify it, but it doesn't help I'm a noob at networking ;)

One moment, firing up a vnet capable box and I'll make sure nothing regressed here.

@Licenser
Copy link
Contributor Author

Awesome thanks! :D I kind of fear my 2 days of FreeBSD experience might be too little to really help with this one.

@skarekrow
Copy link
Member

skarekrow commented Mar 21, 2017

All works here, I tried two different variations, but I did notice a bug that was likely caused by the recent PR to bridges.

TLDR: iocage create tag="vnet_1" -r 11.0-RELEASE ip4_addr="vnet0|192.168.1.70" defaultrouter="192.168.1.1" vnet="on" is working syntax on the latest version from master :)

[root@trueos] ~# iocage create tag="vnet_0" -r 11.0-RELEASE
21896378-7c0f-482f-b158-674308d0c8be (vnet_0) successfully created!
[root@trueos] ~# iocage set ip4_addr="vnet0|192.168.1.71" vnet_0
Property: ip4_addr has been updated to vnet0|192.168.1.71
[root@trueos] ~# iocage set defaultrouter="192.168.1.1" vnet_0
Property: defaultrouter has been updated to 192.168.1.1
[root@trueos] ~# iocage set ip4_addr="vnet0|192.168.1.71" vnet_0
[root@trueos] ~# iocage set vnet="on" vnet_0
Property: vnet has been updated to on
[root@trueos] ~# iocage create tag="vnet_1" -r 11.0-RELEASE ip4_addr="vnet0|192.168.1.70" defaultrouter="192.168.1.1" vnet="on"
2ffc373b-2f96-4ba4-b9d2-89e8341ff5d4 (vnet_1) successfully created!
[root@trueos] ~# iocage start vnet_0
* Starting 21896378-7c0f-482f-b158-674308d0c8be (vnet_0)
  + Started OK

  ERROR: Invalid interface supplied: vnet0
  Did you mean vnet1?

  + Starting services OK
[root@trueos] ~# iocage start vnet_1
* Starting 2ffc373b-2f96-4ba4-b9d2-89e8341ff5d4 (vnet_1)
  + Started OK

  ERROR: Invalid interface supplied: vnet0
  Did you mean vnet1?

  + Starting services OK
[root@trueos] ~# iocage exec vnet_0 ping www.google.com
PING www.google.com (216.58.193.196): 56 data bytes
64 bytes from 216.58.193.196: icmp_seq=0 ttl=49 time=91.480 ms
64 bytes from 216.58.193.196: icmp_seq=1 ttl=49 time=88.216 ms
^C

--- www.google.com ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 88.216/89.848/91.480/1.632 ms
Aborted!
[root@trueos] ~# iocage exec vnet_1 ping www.google.com
PING www.google.com (216.58.193.196): 56 data bytes
64 bytes from 216.58.193.196: icmp_seq=0 ttl=49 time=94.794 ms
64 bytes from 216.58.193.196: icmp_seq=2 ttl=49 time=94.713 ms
^C
--- www.google.com ping statistics ---
3 packets transmitted, 2 packets received, 33.3% packet loss
round-trip min/avg/max/stddev = 94.713/94.754/94.794/0.041 ms

Aborted!
[root@trueos

@Licenser
Copy link
Contributor Author

Thank you!

@Licenser
Copy link
Contributor Author

Sorry not entirely resolved:

changing the IP after vnet=on has been set is what causes the error :)

@skarekrow
Copy link
Member

Can you give me the exact steps you used? vnet=on shouldn't matter at this stage.

@Licenser
Copy link
Contributor Author

Following your steps above and at the very end do:

iocage set ip4_addr="vnet0|192.168.1.73" vnet_0

skarekrow pushed a commit that referenced this issue May 2, 2017
@skarekrow
Copy link
Member

@Licenser well I completely forgot about this! Should be fixed in latest master now 👍

skarekrow pushed a commit that referenced this issue Mar 6, 2019
STABLE: Debugs now correctly start fresh
skarekrow added a commit that referenced this issue Sep 12, 2020
skarekrow added a commit that referenced this issue Sep 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants