09-13-2013 07:59 AM - edited 09-13-2013 08:45 AM
after browsing through this forum and others I am still not confident I fully understood, how the ERP deals with its Ethernet interfaces eth2, eth3 and eth4. So I'd like to lay down, what I've found and would -humbly- request some confirmation and/or correction:
(all assumptions based on v1.3.0alpha2)
- as the ERP comes "out of the box" its ports eth2, eth3 and eth4 behave mostly like eth0 and eth1, except that you (presently?) can neither "bond" them nor make them part of a software switched bridge. The switch0 interface plays no role whatsoever.
This is pretty much, what I have observed, but for one thing: lldp
When I attach a Cisco SG300 switch to eth2 it shows up both on switch0 and on eth2 on the ERP. Bug or feature?
- when I want to use the switch inside the ERP, I have to clean up all L3-stuff from the respective Ethernet interfaces (just leave speed, duplex and poe settings) and make them "part of the switch" by setting the "switch-port interface" nodes inside the switch0 interface. I should then be able to configure L3-addresses on the switch0 interface as usual.
Any "vif" I configure on switch0 should result in tagged frames accepted/emitted on all ports belonging to the switch, right? This I presently cannot confirm, but I need to do a "on desk setup" to make sure I tested right.
Or better asked: Can you provide a (biref) cook-book for all things concerning switch0 and VLANs?
- Hardware "offloading" of IPv6 and IPv4 routing can be used between eth0, eth1 and either the non-switch-part-devices eth2, eth3 and eth4 or switch0, right?
Some remaining questions out of sheer curiosity:
- Will there ever be a switch1, switch2, ...
- Will the "software-bridging" ever be possible between eth0/1 and the other three or switch0?
- Will the "sofwtare-bridging" ever be "offloadable" (thus, effectively becoming close to real switching, performance-wise)?
Otherwise: Well done, guys! I surprise serious router-folks almost every day with the capabilities of your boxes.
Solved! Go to Solution.
09-13-2013 09:32 AM
Yes your observations/understandings are almost all correct, the exception is that offload only applies between eth0, eth1, and switch0. Traffic involving non-switched eth2, eth3, or eth4 will not be offloaded. There were also some related discussions on the forum, for example here and here.
The current implementation constraint regarding bridging is that eth0/1 can be bridged with switch0 but only if all of eth2/3/4 are configured to be switched. On the other hand, eth2/3/4 themselves currently cannot be bridged (nor bonded as you observed). It is possible to remove some of these constraints but it will require changing the low-level implementation so we may not be able to get to that in the short term.
Regarding LLDP, since it uses L2 multicase, currently this is allowed to pass to all interfaces so that is why it shows up on both. This is kind of related to the constraints mentioned above and may change if the low-level implementation is changed in the future.
Regarding bridging offload, as mentioned before we have a basic prototype for it but have not had the resources to finish the implementation and do thorough testing with it. So yes it is possible in the future but currently we don't have a time estimate.
Thanks for the feedback!
09-14-2013 06:12 AM
Thanks, that was very helpful so far.
I'm still curious, though, about the way VLANs are implemented. You carefully avoided this topic in your reply
How do I configure those in the switched variant on an ERP?
Generating a vif 42 on the switch0 interface didn't seem to work in one case where I tried it, but it was a remote setup and I 'm not 100% certain the guy on the other end had his stuff worked out correctly... but is this the way it's supposed to be?
If yes, this would mean, all ports, which are part of the switch, see the same tagged/untagged frames, because I (presently) cannot make them "access" ports in one VLAN, right?
How about offloading, again, in this particular case and in general, when using VLANs (also on the ERL w/ VLANs)?
And: (the bonus question :-) -- any way QinQ would be possible (no need for offloading here)? QinQ would help me a lot in weird situations, where I have multiple VDSL lines, where each of which has a PPPoE session on VLAN#7. With the help of a manageable switch w/ QinQ support (i.e., Cisco SG300) I can thus have multiple, disctinct VLAN#7s ...
Well, I know, this is a weird setup ... I'm just curious, whether it could be done ...
(example syntax: "vif 42 7" or "vif 42.7" (42 = outer, 7 = inner VLAN).
09-14-2013 08:47 AM
Actually as I mentioned above your observations/understandings are almost all correct except for the offload issue, which means the rest of your descriptions (including the VLAN description) are correct. So I'm pretty sure I did not avoid anything.
When the eth2/3/4 ports are switched, they are no longer "visible" individually to the kernel, i.e., from the kernel's point of view it only sees switch0. Therefore in this case the eth0, eth1, and switch0 interfaces on the ER PoE are equivalent to the eth0, eth1, and eth2 interfaces on the ER Lite, respectively. And VLAN offload support has been added in the current alpha software (more info can be found in the release note).
The current CLI configuration does not support QinQ, but it is possible using the Linux "ip" command directly, for example (assuming there is already a VLAN interface eth1.100):
ip link add link eth1.100 name eth1.100.200 type vlan id 200
Note however that this gives you an outer EtherType of 0x8100 (not 0x9100 or 0x88A8), so this may or may not work in your environment.
09-14-2013 11:39 AM
Thanks for the very fast responses!!!
I tested VLANs on a test-ERP and it worked, of course!
The QinQ stuff is way cool! I'll play with it and -if it works satisfactory- I'll try to create the vyatta-templates for it, so it can be used from the normal config CLI - if you don't object.
Again - many thanks for the great support!
09-14-2013 02:08 PM
I am truly sorry to "re-open" this, but now, that I have become best friends with the switch0 interface I have tried to get fancy and realized, that there seem to be quite a few things missing from switch0, that I have on "normal" Ethernet ports, i.e. VRRP ... I had thought, that VRRP is implemented in software and thus shouldn't be affected by the underlying hardware. What gives? (missing "features" marked in bold)
# set switch switch0 ?
address description firewall ipv6 switch-port vif
bridge-group dhcpv6-options ip redirect traffic-policy
# set ethernet eth1 ?
address disable ipv6 pppoe vrrp
bond-group disable-link-detect mac redirect
bridge-group duplex mirror speed
description firewall mtu traffic-policy
dhcpv6-options ip poe vif
Are these features just missing for the time being (I know, this is probably not on top of your todo-list and I don't want to complain!) or are there fundamental hurdles that are not easy to overcome?
BTW: What about "rfc3768‐compatibility" for VRRP? (virtual mac-address)
09-15-2013 09:32 AM
Yes, those features should be supported, but we have not got to them yet (mostly just a matter of resources). On the vmac issue, it is currently not supported due to earlier kernel compatibility issue etc., but we could look into adding this at some point.