Virtual... alias...

[J65nko]

Your ISP's DHCP didn't give an DHCP offer for the vlan device. You can interpret that as a NO

 

[Seeker]

O yeah?
And what, when I boot, without DHCP entry, in rc.conf.
So there is no lease for any device.

Then I initiate dhclient on vlan0 and get nothing.
After that, I initiate dhclient on vr0 and get IP from ISP's DHCP.

How come? No matter if ethers are same, of vr0 and vlan0, or not!

 

[aragon]

Guys! You are totally NOT helping me at all!

On the contrary, you're simply ignoring some of us.

 

[Seeker]

On the contrary, you're simply ignoring some of us.

Am I?
I would call that skipping to longer answers, if one is super short:

Did you bother trying if_bridge(4)?

Tell me...
How would I apply bridge here and what would I achieve?
Bridiging 2 interfaces..., which?
vr0 and... ?

 

[aragon]

I would call that skipping to longer answers, if one is super short:

Skipping, ignoring - doesn't matter what you call it or why you do it, the effect is the same isn't it?

How would I apply bridge here and what would I achieve?

Create the bridge, add vr0 and that's all. Run dhclient against vr0 and again against bridge0. You should get an IP address on each...

The trick now is splitting the traffic between them.

 

[Seeker]

Skipping, ignoring - doesn't matter what you call it or why you do it, the effect is the same isn't it?

I do it, because information is not useful to me, as it is too ambiguous.

Create the bridge, add vr0 and that's all. Run dhclient against vr0 and again against bridge0. You should get an IP address on each...

The trick now is splitting the traffic between them.

Oooo, I see.
I thought I must have at least 2 devices(real or virtual) in order to form a bridge0.
Ok, I will test it then.

 

[aragon]

I do it, because information is not useful to me, as it is too ambiguous.

The best answers are those that make you think for yourself.

Hope it works. FWIW, it works here with my dhcp server...

 

[phoenix]

Guys! You are totally NOT helping me at all! That is so lame!

That's because you refuse to read and comprehend what we are writing. What you want to do is not possible. It's as simple as that.

In order to run mutiple dhclient processes, you MUST have multiple physical NICs. What's so hard to understand? (I've yet to see a setup that can get two separate IPs via DHCP on the same physical NIC.)

As for your new setup, it will not work. Why? Because you have completely misunderstood what 802.1q vLANs are. Without support from the ISP and all the switches/routers between you and your NIC, using vlans will not work.

As I mentioned before, just put a second NIC in the box and be done with it.

 

[Seeker]

The best answers are those that make you think for yourself.

Hope it works. FWIW, it works here with my dhcp server...

Weeeehooo! :e
It works! Kind of...
I get another public IP

Bad thing is... I simply can't access outside world anymore as soon as bridge0 gets leased IP.

# ifconfig bridge0
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        ether 96:a4:7e:77:df:04
        inet 82.a.b.61 netmask 0xfffffc00 broadcast 82.a.b.255
        id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
        maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
        root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
        member: vr0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
                ifmaxaddr 0 port 2 priority 128 path cost 200000

Now you said something about that "trick now is splitting the traffic between them".

 

[Seeker]

...In order to run mutiple dhclient processes, you MUST have multiple physical NICs.

I believe[d] that I MUST have multiple NICs.
But, that it doesn't matter are they physical or virtual, as long as they behave in a same manner and they have unique ethernet address.

What's so hard to understand? (I've yet to see a setup that can get two separate IPs via DHCP on the same physical NIC.)

When it comes to NICs, I believe, that to the other side, physical and virtual NICs, are completely indistinguishable.

Is my assumption correct? :stud

As for your new setup, it will not work. Why? Because you have completely misunderstood what 802.1q vLANs are. Without support from the ISP and all the switches/routers between you and your NIC, using vlans will not work.

I have absolutely(almost), no idea what are you talking about?!? P

As I mentioned before, just put a second NIC in the box and be done with it.

I have no second spare physical NIC.

 

[aragon]

Bad thing is... I simply can't access outside world anymore as soon as bridge0 gets leased IP.

Use tcpdump(1) to figure what is going wrong.

Feel free to paste [CMD=]netstat -rn[/CMD] and [cmd=]ifconfig vr0[/cmd].

 

[Seeker]

# ifconfig vr0
vr0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=2808<VLAN_MTU,WOL_UCAST,WOL_MAGIC>
        ether 00:0b:6a:b8:d6:dc
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active

I've figured out, that at the beginning, when no device has been set IP.
First one, on which I will initiated dhclient, wins.
Meaning that I will use that IP.
Second dhclient call on second device yields new IP, BUT mess up routing table as I've figured out. In red is one being messed up:

Destination        Gateway            Flags    Refs      Use  [color="Red"]Netif[/color] Expire

So it gets fixed when I initiate dhclient again on first device.

But I am sure that I can do it manually now, with route command to edit Netif

Anyway... all this hassle is because I wana more IPs for Apaches IP bassed virtual hosts and each requires dedicated IP or ssl won't work on named virtual hosts.

Also, this doesn't work in rc.conf:

ifconfig_vr0="up"
cloned_interfaces="bridge0"
ifconfig_bridge0="ether 96:a4:7e:77:df:04 addm vr0 DHCP"

At boot time bridge0 doesn't query ISP's DHCP server for new IP, but it does when I do it manually

 

[Seeker]

Oh my god! Oh my god!
Ooooh...., my...., god!

I've figured out, that this won't work, for a very simple reason.
Last IP request, wins!!

So, I can use this only to spoof MAC, nothing more.

I feel so depressed now that I am hitting a road, to have some serious binge!
And to break some bones

...
Hope it works. FWIW, it works here with my dhcp server...

Hm..., up to which extent?

 

[phoenix]

If you compare the IPs, the netmasks, and the default route after each dhclient run, which parts differ?

I'm guessing you are getting IPs in two separate subnets, with two separate defaute routes, which is why the last dhclient run works (it sets the default route to be the one that corresponds to the last IP set).

Unless you get 2 IPs in the same subnet, with the same default route, this won't work -- without some additional trickery.

If you are building a firewall, and want to have 2 public IPs to use for NAT, then you can use IPFW rules to balance traffic across the IPs. You could probably use setfib and vimage as well. But it's a bit hairy to set up.

 

[aragon]

Hm..., up to which extent?

Well, I get two IP addresses, both of which I can use, but unfortunately the source MAC address doesn't follow the source IP address of the related interface. Source MAC is always that of the interface that is set in the routing table. It might be possible to have source IP and source MAC match each other with a pf route-to rule, but I never tested this.

 

[Seeker]

If you compare the IPs, the netmasks, and the default route after each dhclient run, which parts differ?

Everything is same(IPs, the netmasks, and the default route) expect Netif field from [CMD="netstat "]-rn[/CMD]

Destination        Gateway            Flags    Refs      Use  [B][color="DarkRed"]Netif[/color][/B] Expire

Both IPs have a same netmasks and the default route

I didn't tested it thoroughly, but skipped to other test.
That is: (OK means internet accessible, FAIL means internet inaccessible)

Ethernet cable plugged in server and did dhclient vr0 - OK
Unplugged cable from server
Ethernet cable plugged in laptop and did dhclient bge0 - OK
Unplugged cable from laptop
Ethernet cable plugged in server - FAIL
Unplugged cable from server
Ethernet cable plugged in laptop - OK
Unplugged cable from laptop
Ethernet cable plugged in server and did dhclient vr0 - OK
Unplugged cable from server
Ethernet cable plugged in laptop - FAIL

Because of this, I think that ISP has a table, that holds 1 IP for my physical connection, which gets overwritten with new IP entry, as soon as IP is being leased, thus previos ignored and not routed by ISP

Well, I get two IP addresses, both of which I can use...

How do you define IP that you can use?
For me, in this context, that means publicly accessible.

..., but unfortunately the source MAC address doesn't follow the source IP address of the related interface. Source MAC is always that of the interface that is set in the routing table. It might be possible to have source IP and source MAC match each other with a pf route-to rule, but I never tested this.

I skipped hardcore testing and did one from above, without bridge if, for now.

 

[aragon]

How do you define IP that you can use?
For me, in this context, that means publicly accessible.

Depends what you're trying to do, and there's more than one way. Most daemon/server software lets you configure which IP address to listen on, so it's just a matter of configuring it as such, eg. Apache:

Listen <ip>:<port>

Some user/client software lets you configure what address to bind to, eg.

ping -S <src> <dst>

Finally there is libalias(3) or pf(4), but these should usually be a last resort IMHO.