[Xorp-users] VLAN Interfaces

Ben Greear greearb at candelatech.com
Thu Feb 24 16:51:40 PST 2011


On 02/24/2011 02:39 PM, Ray Soucy wrote:
> Sounds great,
>
> Here is a quick text file with some examples in case you want to add
> these to your Wiki.
>
> Is this Wiki public?  If so, it might be useful to share the URL.

I'm happy to add links from the xorp.ct site to external sites
if someone wants to post some.

Also, all the source code for the docs is in the xorp.ct git tree,
so feel free to make changes and submit patches.

Thanks,
Ben

>
> Ray
>
> On Thu, Feb 24, 2011 at 3:55 PM, Pierre Lepropre
> <pierre.lepropre at student.ulg.ac.be>  wrote:
>> Ray,
>>
>> I've been a passive reader of the mailing-list for quite some time now.
>>
>> I'm actually doing my master thesis on XORP and needless to say, I
>> totally agree with you regarding the documentation which is totally
>> useless.
>>
>> Even worse, I do believe that outdated information mislead programmers
>> and discourage many rookies with that system.
>>
>> Right now, every step I make in the right direction is automatically
>> reported on our internal wiki. That takes a lot of time, but I have to
>> do it: somebody has gotta take one for the team !
>>
>> One of my goal is to give public access to that wiki in the future and
>> maybe stimulate enough people to write a new documentation from scratch.
>>
>> I'm still a rookie myself and I haven't written a lot yet but if you
>> wanna take a look, feel free to ask me.
>>
>> Cheers,
>>
>> Pierre.
>>
>> On Thu, 2011-02-24 at 15:22 -0500, Ray Soucy wrote:
>>> I'm not really sure what the best way to address VLAN support in XORP
>>> is.  It's definately broken and it breaks more than just the ability
>>> to create a VLAN interface from XORP.
>>>
>>> In its current design, for a port with one VLAN and no untagged
>>> interface address, it should look like:
>>>
>>>     interface eth0 {
>>>          description: "Trunk Port"
>>>          disable: false
>>>          discard: false
>>>          unreachable: false
>>>          management: false
>>>          vif eth0 {
>>>              disable: false
>>>          }
>>>          vif "eth0.2" {
>>>              disable: false
>>>              vlan-id: 2
>>>              address 192.168.0.1 {
>>>                  prefix-length: 24
>>>                  disable: false
>>>              }
>>>          }
>>>      }
>>>
>>> This would create the sub-interface from XORP.  Or you could import
>>> interfaces created outside of XORP:
>>>
>>>     interface eth0 {
>>>          description: "Trunk Port"
>>>          disable: false
>>>          discard: false
>>>          unreachable: false
>>>          management: false
>>>          default-system-config {
>>>          }
>>>      }
>>>
>>> This is not the case.
>>>
>>> The solution many have discovered, is to create the VLAN interface
>>> outside of XORP, then configure it as a physical interface in XORP.
>>> One would expect that this would look like this:
>>>
>>>     interface "eth0.2" {
>>>          description: "VLAN 2"
>>>          disable: false
>>>          discard: false
>>>          unreachable: false
>>>          management: false
>>>          default-system-config {
>>>          }
>>>      }
>>>
>>> Unfortinately it doesn't seem to.  My guess is that
>>> "default-system-config" can only be applied to a physical interface.
>>>
>>> This would be fine, if using "default-system-config" on the parent
>>> interface would also import sub-interfaces (which I believe was the
>>> intent of how it would work), but that is certainly broken.
>>>
>>> In addition, if you use "default-system-config" on a parent interface,
>>> but explicitly deinfe a sub-interface, that will break XORP interface
>>> indexing as well.
>>>
>>> In its current state the only way to get around this is to explicitly
>>> define the IP address of any interface using VLAN's and define all
>>> VLAN sub-interfaces as if they were physical interfaces (even if you
>>> don't give the untagged interface an address):
>>>
>>>     interface eth0 {
>>>          description: "Trunk Port"
>>>          disable: false
>>>          discard: false
>>>          unreachable: false
>>>          management: false
>>>          vif eth0 {
>>>              disable: false
>>>          }
>>>     }
>>>     interface "eth0.2" {
>>>          description: "VLAN 2"
>>>          disable: false
>>>          discard: false
>>>          unreachable: false
>>>          management: false
>>>          vif "eth0.2" {
>>>              disable: false
>>>              address 192.168.0.1 {
>>>                  prefix-length: 24
>>>                  disable: false
>>>              }
>>>          }
>>>      }
>>>
>>> While you could change XORP to better support defining VLAN interfaces
>>> as if they were physical interfaces rather than VIF's, I think this
>>> would ultimately break more of XORP (because everything seems to be
>>> designed around this concept of how interfaces are represented) and
>>> ultimately be more work than trying to fix the original design.
>>>
>>> Either way, I think the documentation might need to be updated to
>>> reflect the current state of VLAN support so we see less frustration
>>> towards XORP and perhaps more community support.
>>>
>>> On Tue, Feb 15, 2011 at 3:25 PM, Joe Coco<jcoco at meccorp.mec.edu>  wrote:
>>>>> Yes, but the interface will not be admin up, and all sorts of code will not
>>>>> actually function properly.
>>>>
>>>> How do you tell if it is 'admin up' ?
>>>>
>>>> The hack I wrote, seems to make it work although I have not tested much more than basic pinging.
>>>>
>>>> xorp at asterisk# show interfaces interface eth1
>>>>     description: "Eth1"
>>>>     vif "eth1.100" {
>>>>         vlan {
>>>>             vlan-id: 100
>>>>         }
>>>>         address 1.1.1.1 {
>>>>             prefix-length: 24
>>>>         }
>>>>     }
>>>>     vif "eth2.100" {
>>>>         vlan {
>>>>             vlan-id: 200
>>>>         }
>>>>         address 2.1.1.1 {
>>>>             prefix-length: 24
>>>>         }
>>>>     }
>>>>
>>>> [edit]
>>>> xorp at asterisk#
>>>>
>>>>
>>>>> I remain convinced that making the vlans a normal interface in the config file
>>>>> (and xorpsh), and adding some vlan-id and parent-dev fields so that we can
>>>>> create them properly is the way to actually get this working.
>>>>
>>>>> This would still be a decent amount of work...
>>>>
>>>> Probably. ZebOS does this kind of. You set switchport access under the physical interface (which vlans can pass), but the actual
>>>> 'vif' is a vlanvid device that is treated like a normal interface not attached to the physical. With this config for example, you can
>>>> put eth1 and eth2 both in vlan5 in bridge mode.
>>>>
>>>> If we could do something as simple as:
>>>>
>>>> # create interface vlan 100 disable false
>>>> # create interface vlan 100 physical eth1 mode trunk
>>>> # create interface vlan 100 physical eth2 mode access
>>>> # create interface vlan 100 bridge-id 1
>>>> # create interface vlan 100 address 1.1.1.1 prefix-length 24
>>>>
>>>> Which would then create a vlan100 interface, I think that would work just fine.
>>>> In the above example, it would be in trunk (tag) mode on eth1, but native access
>>>> mode on eth2 with a bridge group of 1. This could be built on for q-in-q support, etc.
>>>>
>>>> -- Joe
>>>>
>>>>
>>>>
>>>>
>>>> -- Joe
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Xorp-users mailing list
>>>> Xorp-users at xorp.org
>>>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>>>>
>>>
>>
>>
>>
>
>
>
>
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



More information about the Xorp-users mailing list