From dmoormann at meccorp.mec.edu  Tue Feb  8 07:38:40 2011
From: dmoormann at meccorp.mec.edu (Dan Moormann)
Date: Tue, 8 Feb 2011 10:38:40 -0500
Subject: [Xorp-users] VLAN Interfaces
Message-ID: <C976CB8C.23399%dmoormann@meccorp.mec.edu>

We've recently started to test xorp.ct 1.8 and are experiencing difficulty adding ip4 addresses to vlan vif's.  Using xorpsh, the vlan looks as though its being created when we look in /proc/net/vlan we see that it there. Though it takes the configuration, shows up in the configuration, and "run show interfaces", it does not show up using ifconfig or ip route from the shell.  We have found that creating the vlan with vconfig then going into xorpsh and configuring "interface vlan100 vif vlan100 address..." works.  Is anyone else having this problem?

Thanks
Dan


From greearb at candelatech.com  Tue Feb  8 09:07:52 2011
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 08 Feb 2011 09:07:52 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <C976CB8C.23399%dmoormann@meccorp.mec.edu>
References: <C976CB8C.23399%dmoormann@meccorp.mec.edu>
Message-ID: <4D517868.20205@candelatech.com>

On 02/08/2011 07:38 AM, Dan Moormann wrote:
> We've recently started to test xorp.ct 1.8 and are experiencing difficulty adding ip4 addresses to vlan vif's.  Using xorpsh, the vlan looks as though its being created when we look in /proc/net/vlan we see that it there. Though it takes the configuration, shows up in the configuration, and "run show interfaces", it does not show up using ifconfig or ip route from the shell.  We have found that creating the vlan with vconfig then going into xorpsh and configuring "interface vlan100 vif vlan100 address..." works.  Is anyone else having this problem?

I've always created vlans outside of xorp and treated them as regular interfaces
within xorp.

Thanks,
Ben

>
> Thanks
> Dan
>
> _______________________________________________
> 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


From dmoormann at meccorp.mec.edu  Tue Feb  8 10:23:43 2011
From: dmoormann at meccorp.mec.edu (Dan Moormann)
Date: Tue, 8 Feb 2011 13:23:43 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D517868.20205@candelatech.com>
Message-ID: <C976F238.233BF%dmoormann@meccorp.mec.edu>

Thanks for the quick response Ben.  I can do that, and have found it works.  I was hoping
To be able to do this all from the xorpsh shell though to limit the number of things that
Have to be done outside the xorpsh.


On 2/8/11 12:07 PM, "Ben Greear" <greearb at candelatech.com> wrote:

On 02/08/2011 07:38 AM, Dan Moormann wrote:
> We've recently started to test xorp.ct 1.8 and are experiencing difficulty adding ip4 addresses to vlan vif's.  Using xorpsh, the vlan looks as though its being created when we look in /proc/net/vlan we see that it there. Though it takes the configuration, shows up in the configuration, and "run show interfaces", it does not show up using ifconfig or ip route from the shell.  We have found that creating the vlan with vconfig then going into xorpsh and configuring "interface vlan100 vif vlan100 address..." works.  Is anyone else having this problem?

I've always created vlans outside of xorp and treated them as regular interfaces
within xorp.

Thanks,
Ben

>
> Thanks
> Dan
>
> _______________________________________________
> 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




From greearb at candelatech.com  Tue Feb  8 12:05:03 2011
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 08 Feb 2011 12:05:03 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <C976F238.233BF%dmoormann@meccorp.mec.edu>
References: <C976F238.233BF%dmoormann@meccorp.mec.edu>
Message-ID: <4D51A1EF.3010608@candelatech.com>

On 02/08/2011 10:23 AM, Dan Moormann wrote:
> Thanks for the quick response Ben.  I can do that, and have found it works.  I was hoping
> To be able to do this all from the xorpsh shell though to limit the number of things that
> Have to be done outside the xorpsh.
>
>
> On 2/8/11 12:07 PM, "Ben Greear"<greearb at candelatech.com>  wrote:
>
> On 02/08/2011 07:38 AM, Dan Moormann wrote:
>> We've recently started to test xorp.ct 1.8 and are experiencing difficulty adding ip4 addresses to vlan vif's.  Using xorpsh, the vlan looks as though its being created when we look in /proc/net/vlan we see that it there. Though it takes the configuration, shows up in the configuration, and "run show interfaces", it does not show up using ifconfig or ip route from the shell.  We have found that creating the vlan with vconfig then going into xorpsh and configuring "interface vlan100 vif vlan100 address..." works.  Is anyone else having this problem?
>
> I've always created vlans outside of xorp and treated them as regular interfaces
> within xorp.

Well, take a peek at the xorp logs and see if you see anything interesting.

Did this work on previous xorp releases?  (I'm not at all certain it
would, just curious.)

I don't have time to look into this myself right now, but can review
patches and hopefully answer questions, and will try to take a look
at the problem when I get a chance.

Thanks,
Ben

>
> Thanks,
> Ben
>
>>
>> Thanks
>> Dan
>>
>> _______________________________________________
>> 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
>


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


From esj at cs.fiu.edu  Tue Feb  8 12:24:05 2011
From: esj at cs.fiu.edu (Eric S. Johnson)
Date: Tue, 08 Feb 2011 15:24:05 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D51A1EF.3010608@candelatech.com> 
References: <C976F238.233BF%dmoormann@meccorp.mec.edu>
	<4D51A1EF.3010608@candelatech.com>
Message-ID: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>


greearb at candelatech.com said:
> Did this work on previous xorp releases?  (I'm not at all certain it
> would, just curious.) 


Nope. It hasn't worked (with a linux kernel) since 1.6. I remember when 
I looked into the code I came away thinking it might have worked with
freebsd kernels once upon a time...

I too create the vlan interfaces outside of xorp (using the distro 
standard method) and then have lots of config lines like:

...
    interface "eth0.10" {
        description: ""
        disable: false
        discard: false
        unreachable: false
        management: false
        vif "eth0.10" {
            disable: false
            address x.x.x.x {
                prefix-length: 26
                disable: false
            }
        }
    }
...



From andriysenkovych at gmail.com  Wed Feb  9 05:52:58 2011
From: andriysenkovych at gmail.com (Andriy Senkovych)
Date: Wed, 9 Feb 2011 15:52:58 +0200
Subject: [Xorp-users] Problem setting up PIM-SM with Cisco on Amazon EC2
Message-ID: <AANLkTik6+3p0GuKy4TA-GdssvMAsNLC8FvbYc=HzQCz6@mail.gmail.com>

Dear xorp experts,

I have a problem configuring PIM-SM on Amazon EC2. The problem is that
xorp doesn't send PIM_JOIN_PRUNE to the RP when client joins the
group. Here are some notes on my configuration:

Network:
Client (10.100.123.102/30) --- GRE tun123101 --- (10.100.123.101/30 )
XORP (10.100.247.102/30) --- GRE tun247102 --- Cisco
(10.100.247.101/30)

GRE tunnels are wrapped over IPSec and seem to work well (i.e. I could
send and recieve multicast through the tunnel with no packet loss).

I've got the Cisco-like configuration for XORP from the data provider:

ip multicast-routing
!
access-list 2 permit 239.1.10.0 0.0.0.255
access-list 3 permit 239.1.20.0 0.0.0.255
ip pim rp-address 192.168.0.21 2 override
ip pim rp-address 192.168.0.11 3 override
!
ip pim autorp listener
ip pim spt-threshold infinity
no ip pim dm-fallback

So I translated it into xorp's configuration (attached)

When started, xorp finds Cisco neighbour and Cisco also discovers xorp:

> show pim interfaces
Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
tun123101    UP       Sparse 2 DR              1 10.100.123.101          0
tun247102    UP       Sparse 2 DR              1 10.100.247.102          1
register_vif DISABLED Sparse 2 DR              1 10.100.247.102          0

> show pim neighbors
Interface ? ?DRpriority NeighborAddr ? ?V Mode ? Holdtime Timeout
tun247102 ? ? ? ? ? ? 1 10.100.247.101 ?2 Sparse ? ? ?105 ? ? ?87

And we have some static configured RPs:

> show pim rps
RP ? ? ? ? ? ? ?Type ? ? ?Pri Holdtime Timeout ActiveGroups GroupPrefix
192.168.0.21 ? ?static ? ?192 ? ? ? -1 ? ? ?-1 ? ? ? ? ? ?0 239.1.10.0/24
192.168.0.11 ? ?static ? ?192 ? ? ? -1 ? ? ?-1 ? ? ? ? ? ?0 239.1.20.0/24

Both Cisco and xorp recieve and transfer PIM_HELLO normally.

When the client joins 239.1.20.54:4457 group xorp has the following in its log:

[ 2011/02/09 12:55:51 TRACE xorp_pimsm4 PIM ] Add membership for
(0.0.0.0, 239.1.20.54) on vif tun123101
[ 2011/02/09 12:55:51 TRACE xorp_pimsm4 PIM ] TX PIM_JOIN_PRUNE from
10.100.247.102 to 224.0.0.13 on vif tun247102
[ 2011/02/09 12:55:51 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 10.100.123.102 to 239.1.20.54 on vif
tun123101
[ 2011/02/09 12:55:51 TRACE xorp_igmp MLD6IGMP ] Notify routing add
membership for (0.0.0.0, 239.1.20.54) on vif tun123101
[ 2011/02/09 12:55:55 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 10.100.123.102 to 239.1.20.54 on vif
tun123101
[ 2011/02/09 12:56:00 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_MEMBERSHIP_REPORT from 10.100.123.102 to 239.1.20.54 on vif
tun123101

After this I believe there should be some PIM_JOIN_PRUNE message
telling RP that I'd like to recieve traffic for this group but this
doesn't. Cisco doesn't seem to recieve join messages from xorp too.

When I stop client I get the following:
[ 2011/02/09 13:36:42 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_V2_LEAVE_GROUP from 10.100.123.102 to 224.0.0.2 on vif tun123101
[ 2011/02/09 13:36:42 TRACE xorp_igmp MLD6IGMP ] TX
IGMP_MEMBERSHIP_QUERY from 10.100.123.101 to 239.1.20.54
[ 2011/02/09 13:36:42 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_MEMBERSHIP_QUERY from 10.100.123.101 to 239.1.20.54 on vif
tun123101
[ 2011/02/09 13:36:43 TRACE xorp_igmp MLD6IGMP ] TX
IGMP_MEMBERSHIP_QUERY from 10.100.123.101 to 239.1.20.54
[ 2011/02/09 13:36:43 TRACE xorp_igmp MLD6IGMP ] RX
IGMP_MEMBERSHIP_QUERY from 10.100.123.101 to 239.1.20.54 on vif
tun123101
[ 2011/02/09 13:36:44 TRACE xorp_igmp MLD6IGMP ] Notify routing delete
membership for (0.0.0.0, 239.1.20.54) on vif tun123101
[ 2011/02/09 13:36:44 TRACE xorp_pimsm4 PIM ] Delete membership for
(0.0.0.0, 239.1.20.54) on vif tun123101
[ 2011/02/09 13:36:44 TRACE xorp_pimsm4 PIM ] TX PIM_JOIN_PRUNE from
10.100.247.102 to 224.0.0.13 on vif tun247102


Here is some additional information from xorp:

> show pim mfc
Group           Source          RP
224.0.1.39      194.247.133.211 0.0.0.0
    Incoming interface :      tun247102
    Outgoing interfaces:      ...
224.0.1.39      194.247.133.221 0.0.0.0
    Incoming interface :      tun247102
    Outgoing interfaces:      ...
224.0.1.40      194.247.133.211 0.0.0.0
    Incoming interface :      tun247102
    Outgoing interfaces:      ...
224.0.1.40      194.247.133.221 0.0.0.0
    Incoming interface :      tun247102
    Outgoing interfaces:      ...

> show pim join
Group           Source          RP              Flags
239.1.20.54     0.0.0.0         192.168.0.11    WC
    Upstream interface (RP):   tun247102
    Upstream MRIB next hop (RP): 10.100.247.101
    Upstream RPF'(*,G):        10.100.247.101
    Upstream state:            Joined
    Join timer:                6
    Local receiver include WC: O..
    Joins RP:                  ...
    Joins WC:                  ...
    Join state:                ...
    Prune state:               ...
    Prune pending state:       ...
    I am assert winner state:  ...
    I am assert loser state:   ...
    Assert winner WC:          ...
    Assert lost WC:            ...
    Assert tracking WC:        OO.
    Could assert WC:           O..
    I am DR:                   OOO
    Immediate olist RP:        ...
    Immediate olist WC:        O..
    Inherited olist SG:        O..
    Inherited olist SG_RPT:    O..
    PIM include WC:            O..


Additional things I've checked and tried:

1) Kernel configuration: seems to be fine since "cat
/proc/sys/net/ipv4/conf/tun*/mc_forwarding" shows 1
2) /proc/sys/net/ipv4/conf/all/forwarding set to 1 (for tunnels either)
3) Unfortunately everything is encapsulated with IPSec so tcpdump
didn't help me.
4) Trying to launch client on the same machine as router

I used Ubuntu 10.04.2 LTS image from Canonical with 2.6.32-312-ec2
kernel for this test, xorp version 1.6. Unfortunately I cannot exactly
determine exact config options, but since this is image provided by
Canonical there should be original Ubuntu kernel which has all the
options enabled.

In addition I tried to configure pimd since it seemed more lightweight
at that moment but ended with the same result except that It was
harder to debug with no documentation (test cases for PIM-SM provided
by xorp are really good).

Also I'd like to know how to configure xorp so running multicast
client on the router would be possible.

Thanks in advance.
--
WBR, Andriy Senkovych
-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.boot
Type: application/octet-stream
Size: 1899 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110209/0344385d/attachment.obj 

From greearb at candelatech.com  Wed Feb  9 14:21:50 2011
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 09 Feb 2011 14:21:50 -0800
Subject: [Xorp-users] Problem setting up PIM-SM with Cisco on Amazon EC2
In-Reply-To: <AANLkTik6+3p0GuKy4TA-GdssvMAsNLC8FvbYc=HzQCz6@mail.gmail.com>
References: <AANLkTik6+3p0GuKy4TA-GdssvMAsNLC8FvbYc=HzQCz6@mail.gmail.com>
Message-ID: <4D53137E.8080209@candelatech.com>

On 02/09/2011 05:52 AM, Andriy Senkovych wrote:
> Dear xorp experts,
>
> I have a problem configuring PIM-SM on Amazon EC2. The problem is that
> xorp doesn't send PIM_JOIN_PRUNE to the RP when client joins the
> group. Here are some notes on my configuration:
>
> Network:
> Client (10.100.123.102/30) --- GRE tun123101 --- (10.100.123.101/30 )
> XORP (10.100.247.102/30) --- GRE tun247102 --- Cisco
> (10.100.247.101/30)
>
> GRE tunnels are wrapped over IPSec and seem to work well (i.e. I could
> send and recieve multicast through the tunnel with no packet loss).
>
> I've got the Cisco-like configuration for XORP from the data provider:
>
> ip multicast-routing
> !
> access-list 2 permit 239.1.10.0 0.0.0.255
> access-list 3 permit 239.1.20.0 0.0.0.255
> ip pim rp-address 192.168.0.21 2 override
> ip pim rp-address 192.168.0.11 3 override
> !
> ip pim autorp listener
> ip pim spt-threshold infinity
> no ip pim dm-fallback
>
> So I translated it into xorp's configuration (attached)
>
> When started, xorp finds Cisco neighbour and Cisco also discovers xorp:
>
>> show pim interfaces
> Interface    State    Mode   V PIMstate Priority DRaddr          Neighbors
> tun123101    UP       Sparse 2 DR              1 10.100.123.101          0
> tun247102    UP       Sparse 2 DR              1 10.100.247.102          1
> register_vif DISABLED Sparse 2 DR              1 10.100.247.102          0
>
>> show pim neighbors
> Interface    DRpriority NeighborAddr    V Mode   Holdtime Timeout
> tun247102             1 10.100.247.101  2 Sparse      105      87
>
> And we have some static configured RPs:
>
>> show pim rps
> RP              Type      Pri Holdtime Timeout ActiveGroups GroupPrefix
> 192.168.0.21    static    192       -1      -1            0 239.1.10.0/24
> 192.168.0.11    static    192       -1      -1            0 239.1.20.0/24
>
> Both Cisco and xorp recieve and transfer PIM_HELLO normally.
>
> When the client joins 239.1.20.54:4457 group xorp has the following in its log:
>
> [ 2011/02/09 12:55:51 TRACE xorp_pimsm4 PIM ] Add membership for
> (0.0.0.0, 239.1.20.54) on vif tun123101
> [ 2011/02/09 12:55:51 TRACE xorp_pimsm4 PIM ] TX PIM_JOIN_PRUNE from
> 10.100.247.102 to 224.0.0.13 on vif tun247102
> [ 2011/02/09 12:55:51 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 10.100.123.102 to 239.1.20.54 on vif
> tun123101
> [ 2011/02/09 12:55:51 TRACE xorp_igmp MLD6IGMP ] Notify routing add
> membership for (0.0.0.0, 239.1.20.54) on vif tun123101
> [ 2011/02/09 12:55:55 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 10.100.123.102 to 239.1.20.54 on vif
> tun123101
> [ 2011/02/09 12:56:00 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_MEMBERSHIP_REPORT from 10.100.123.102 to 239.1.20.54 on vif
> tun123101
>
> After this I believe there should be some PIM_JOIN_PRUNE message
> telling RP that I'd like to recieve traffic for this group but this
> doesn't. Cisco doesn't seem to recieve join messages from xorp too.
>
> When I stop client I get the following:
> [ 2011/02/09 13:36:42 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_V2_LEAVE_GROUP from 10.100.123.102 to 224.0.0.2 on vif tun123101
> [ 2011/02/09 13:36:42 TRACE xorp_igmp MLD6IGMP ] TX
> IGMP_MEMBERSHIP_QUERY from 10.100.123.101 to 239.1.20.54
> [ 2011/02/09 13:36:42 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_MEMBERSHIP_QUERY from 10.100.123.101 to 239.1.20.54 on vif
> tun123101
> [ 2011/02/09 13:36:43 TRACE xorp_igmp MLD6IGMP ] TX
> IGMP_MEMBERSHIP_QUERY from 10.100.123.101 to 239.1.20.54
> [ 2011/02/09 13:36:43 TRACE xorp_igmp MLD6IGMP ] RX
> IGMP_MEMBERSHIP_QUERY from 10.100.123.101 to 239.1.20.54 on vif
> tun123101
> [ 2011/02/09 13:36:44 TRACE xorp_igmp MLD6IGMP ] Notify routing delete
> membership for (0.0.0.0, 239.1.20.54) on vif tun123101
> [ 2011/02/09 13:36:44 TRACE xorp_pimsm4 PIM ] Delete membership for
> (0.0.0.0, 239.1.20.54) on vif tun123101
> [ 2011/02/09 13:36:44 TRACE xorp_pimsm4 PIM ] TX PIM_JOIN_PRUNE from
> 10.100.247.102 to 224.0.0.13 on vif tun247102
>
>
> Here is some additional information from xorp:
>
>> show pim mfc
> Group           Source          RP
> 224.0.1.39      194.247.133.211 0.0.0.0
>      Incoming interface :      tun247102
>      Outgoing interfaces:      ...
> 224.0.1.39      194.247.133.221 0.0.0.0
>      Incoming interface :      tun247102
>      Outgoing interfaces:      ...
> 224.0.1.40      194.247.133.211 0.0.0.0
>      Incoming interface :      tun247102
>      Outgoing interfaces:      ...
> 224.0.1.40      194.247.133.221 0.0.0.0
>      Incoming interface :      tun247102
>      Outgoing interfaces:      ...
>
>> show pim join
> Group           Source          RP              Flags
> 239.1.20.54     0.0.0.0         192.168.0.11    WC
>      Upstream interface (RP):   tun247102
>      Upstream MRIB next hop (RP): 10.100.247.101
>      Upstream RPF'(*,G):        10.100.247.101
>      Upstream state:            Joined
>      Join timer:                6
>      Local receiver include WC: O..
>      Joins RP:                  ...
>      Joins WC:                  ...
>      Join state:                ...
>      Prune state:               ...
>      Prune pending state:       ...
>      I am assert winner state:  ...
>      I am assert loser state:   ...
>      Assert winner WC:          ...
>      Assert lost WC:            ...
>      Assert tracking WC:        OO.
>      Could assert WC:           O..
>      I am DR:                   OOO
>      Immediate olist RP:        ...
>      Immediate olist WC:        O..
>      Inherited olist SG:        O..
>      Inherited olist SG_RPT:    O..
>      PIM include WC:            O..
>
>
> Additional things I've checked and tried:
>
> 1) Kernel configuration: seems to be fine since "cat
> /proc/sys/net/ipv4/conf/tun*/mc_forwarding" shows 1
> 2) /proc/sys/net/ipv4/conf/all/forwarding set to 1 (for tunnels either)
> 3) Unfortunately everything is encapsulated with IPSec so tcpdump
> didn't help me.
> 4) Trying to launch client on the same machine as router
>
> I used Ubuntu 10.04.2 LTS image from Canonical with 2.6.32-312-ec2
> kernel for this test, xorp version 1.6. Unfortunately I cannot exactly
> determine exact config options, but since this is image provided by
> Canonical there should be original Ubuntu kernel which has all the
> options enabled.
>
> In addition I tried to configure pimd since it seemed more lightweight
> at that moment but ended with the same result except that It was
> harder to debug with no documentation (test cases for PIM-SM provided
> by xorp are really good).
>
> Also I'd like to know how to configure xorp so running multicast
> client on the router would be possible.

You might try xorp.ct, but I'm not sure if it will help your
particular problem.

Also, perhaps the problem is that you are not
using spt?  I think that keeps traffic out of
the kernel routing tables and just uses messages
sent directly to/from the router processes.

switch-to-spt-threshold {
             disable: true
}

Thanks,
Ben

>
> Thanks in advance.
> --
> WBR, Andriy Senkovych
>
>
>
> _______________________________________________
> 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


From andriysenkovych at gmail.com  Wed Feb  9 15:14:50 2011
From: andriysenkovych at gmail.com (Andriy Senkovych)
Date: Thu, 10 Feb 2011 01:14:50 +0200
Subject: [Xorp-users] Problem setting up PIM-SM with Cisco on Amazon EC2
In-Reply-To: <4D53137E.8080209@candelatech.com>
References: <AANLkTik6+3p0GuKy4TA-GdssvMAsNLC8FvbYc=HzQCz6@mail.gmail.com>
	<4D53137E.8080209@candelatech.com>
Message-ID: <AANLkTimCOSOaCFPFx9HEEciCDOYV=z1m5ydfdxPBK6Vh@mail.gmail.com>

Hello, Ben!

Thanks for your reply.


> You might try xorp.ct, but I'm not sure if it will help your
> particular problem.
>
> Also, perhaps the problem is that you are not
> using spt? ?I think that keeps traffic out of
> the kernel routing tables and just uses messages
> sent directly to/from the router processes.
>
> switch-to-spt-threshold {
> ? ? ? ? ? ?disable: true
> }

I tried this option both enabled and disabled with no significant
difference, so it seems this shouldn't be it. I just wanted to be
precise to the cisco-like configuration the other side sent.

There's a strange thing.. I tried once to increase TTL of the messages
sent by reciever and got some new output:

[ 2011/02/09 22:41:08 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from
10.100.123.101 to 224.0.0.13 on vif tun123101
[ 2011/02/09 22:41:08 TRACE xorp_pimsm4 PIM ] RX NOCACHE signal from
MFEA_4: vif_index = 1 src = 194.247.133.242 dst = 239.10.20.30
[ 2011/02/09 22:41:08 TRACE xorp_pimsm4 PIM ] Add MFC entry:
(194.247.133.242, 239.10.20.30) iif = 1 olist = O..
olist_disable_wrongvif = .OO
[ 2011/02/09 22:41:08 TRACE xorp_pimsm4 PIM ] Add dataflow monitor:
source = 194.247.133.242 group = 239.10.20.30 threshold_interval_sec =
210 threshold_interval_usec = 0 threshold_packets = 0 threshold_bytes
= 0 is_threshold_in_packets = 1 is_threshold_in_bytes = 0
is_geq_upcall = 0 is_leq_upcall = 1
[ 2011/02/09 22:41:08 TRACE xorp_fea MFEA ] RX kernel signal:
message_type = 1 vif_index = 1 src = 194.247.133.242 dst =
239.10.20.30
[ 2011/02/09 22:41:08 TRACE xorp_fea MFEA ] Add MFC entry:
(194.247.133.242, 239.10.20.30) iif = 1 olist = O..

And mfc also has this new record:

> show pim mfc
239.10.20.30    194.247.133.242 194.247.133.211
    Incoming interface :      tun247102
    Outgoing interfaces:      O..

And since that time I always get this response even without setting up
TTL. I think someone has done something on the other side. I'll get
the details from the remote side and be back.

BTW, do these log lines show that xorp request has successfully reached RP?

Thanks.
-- 
WBR, Andriy Senkovych


From greearb at candelatech.com  Wed Feb  9 15:16:51 2011
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 09 Feb 2011 15:16:51 -0800
Subject: [Xorp-users] Problem setting up PIM-SM with Cisco on Amazon EC2
In-Reply-To: <AANLkTimCOSOaCFPFx9HEEciCDOYV=z1m5ydfdxPBK6Vh@mail.gmail.com>
References: <AANLkTik6+3p0GuKy4TA-GdssvMAsNLC8FvbYc=HzQCz6@mail.gmail.com>	<4D53137E.8080209@candelatech.com>
	<AANLkTimCOSOaCFPFx9HEEciCDOYV=z1m5ydfdxPBK6Vh@mail.gmail.com>
Message-ID: <4D532063.1040808@candelatech.com>

On 02/09/2011 03:14 PM, Andriy Senkovych wrote:
> Hello, Ben!
>
> Thanks for your reply.
>
>
>> You might try xorp.ct, but I'm not sure if it will help your
>> particular problem.
>>
>> Also, perhaps the problem is that you are not
>> using spt?  I think that keeps traffic out of
>> the kernel routing tables and just uses messages
>> sent directly to/from the router processes.
>>
>> switch-to-spt-threshold {
>>             disable: true
>> }
>
> I tried this option both enabled and disabled with no significant
> difference, so it seems this shouldn't be it. I just wanted to be
> precise to the cisco-like configuration the other side sent.
>
> There's a strange thing.. I tried once to increase TTL of the messages
> sent by reciever and got some new output:
>
> [ 2011/02/09 22:41:08 TRACE xorp_pimsm4 PIM ] TX PIM_HELLO from
> 10.100.123.101 to 224.0.0.13 on vif tun123101
> [ 2011/02/09 22:41:08 TRACE xorp_pimsm4 PIM ] RX NOCACHE signal from
> MFEA_4: vif_index = 1 src = 194.247.133.242 dst = 239.10.20.30
> [ 2011/02/09 22:41:08 TRACE xorp_pimsm4 PIM ] Add MFC entry:
> (194.247.133.242, 239.10.20.30) iif = 1 olist = O..
> olist_disable_wrongvif = .OO
> [ 2011/02/09 22:41:08 TRACE xorp_pimsm4 PIM ] Add dataflow monitor:
> source = 194.247.133.242 group = 239.10.20.30 threshold_interval_sec =
> 210 threshold_interval_usec = 0 threshold_packets = 0 threshold_bytes
> = 0 is_threshold_in_packets = 1 is_threshold_in_bytes = 0
> is_geq_upcall = 0 is_leq_upcall = 1
> [ 2011/02/09 22:41:08 TRACE xorp_fea MFEA ] RX kernel signal:
> message_type = 1 vif_index = 1 src = 194.247.133.242 dst =
> 239.10.20.30
> [ 2011/02/09 22:41:08 TRACE xorp_fea MFEA ] Add MFC entry:
> (194.247.133.242, 239.10.20.30) iif = 1 olist = O..
>
> And mfc also has this new record:
>
>> show pim mfc
> 239.10.20.30    194.247.133.242 194.247.133.211
>      Incoming interface :      tun247102
>      Outgoing interfaces:      O..
>
> And since that time I always get this response even without setting up
> TTL. I think someone has done something on the other side. I'll get
> the details from the remote side and be back.
>
> BTW, do these log lines show that xorp request has successfully reached RP?

I struggle every time I try to debug multicast, but you certainly
need at TTL large enough to cover all your router hops.

Thanks,
Ben

>
> Thanks.


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


From andriysenkovych at gmail.com  Wed Feb  9 15:56:37 2011
From: andriysenkovych at gmail.com (Andriy Senkovych)
Date: Thu, 10 Feb 2011 01:56:37 +0200
Subject: [Xorp-users] Problem setting up PIM-SM with Cisco on Amazon EC2
In-Reply-To: <4D532063.1040808@candelatech.com>
References: <AANLkTik6+3p0GuKy4TA-GdssvMAsNLC8FvbYc=HzQCz6@mail.gmail.com>
	<4D53137E.8080209@candelatech.com>
	<AANLkTimCOSOaCFPFx9HEEciCDOYV=z1m5ydfdxPBK6Vh@mail.gmail.com>
	<4D532063.1040808@candelatech.com>
Message-ID: <AANLkTinycvDuxmU-HsXYZdzqbSmpDdhnjna+u9Aep6+1@mail.gmail.com>

Hello, Ben!

> I struggle every time I try to debug multicast, but you certainly
> need at TTL large enough to cover all your router hops.

Isn't TTL supposed to mean a lot for sender only? I thought IGMP join
messages should just reach DR who is on the same net so TTL=1 for
receiver should be sufficient.

I played with TTL for receiver only, since i don't have an access to
sender. However this is already on my troubleshooting list for the
provider's tech support.

Thanks.

-- 
WBR, Andriy Senkovych


From greearb at candelatech.com  Wed Feb  9 16:24:18 2011
From: greearb at candelatech.com (Ben Greear)
Date: Wed, 09 Feb 2011 16:24:18 -0800
Subject: [Xorp-users] Problem setting up PIM-SM with Cisco on Amazon EC2
In-Reply-To: <AANLkTinycvDuxmU-HsXYZdzqbSmpDdhnjna+u9Aep6+1@mail.gmail.com>
References: <AANLkTik6+3p0GuKy4TA-GdssvMAsNLC8FvbYc=HzQCz6@mail.gmail.com>	<4D53137E.8080209@candelatech.com>	<AANLkTimCOSOaCFPFx9HEEciCDOYV=z1m5ydfdxPBK6Vh@mail.gmail.com>	<4D532063.1040808@candelatech.com>
	<AANLkTinycvDuxmU-HsXYZdzqbSmpDdhnjna+u9Aep6+1@mail.gmail.com>
Message-ID: <4D533032.2090100@candelatech.com>

On 02/09/2011 03:56 PM, Andriy Senkovych wrote:
> Hello, Ben!
>
>> I struggle every time I try to debug multicast, but you certainly
>> need at TTL large enough to cover all your router hops.
>
> Isn't TTL supposed to mean a lot for sender only? I thought IGMP join
> messages should just reach DR who is on the same net so TTL=1 for
> receiver should be sufficient.
>
> I played with TTL for receiver only, since i don't have an access to
> sender. However this is already on my troubleshooting list for the
> provider's tech support.

TTL on receiver should mean nothing at all, as far as I know.

It definitely matters on the sender.

You could sniff the pkts coming in from the sender to make
sure they have an appropriate TTL.

Thanks,
Ben

>
> Thanks.
>


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


From jcoco at meccorp.mec.edu  Fri Feb 11 10:41:29 2011
From: jcoco at meccorp.mec.edu (Joe Coco)
Date: Fri, 11 Feb 2011 13:41:29 -0500
Subject: [Xorp-users] VLAN Interfaces
Message-ID: <65A6944974518C4B9C0E818727B559E9397F8435@mecexchange2007.meccorp.mec.edu>

Hello everyone,

>Nope. It hasn't worked (with a linux kernel) since 1.6. I remember when
> I looked into the code I came away thinking it might have worked with
> freebsd kernels once upon a time...

This may very well end up in the development list, but for now.

The problem, the way I see it is, the code is set up to create VLAN's using the VLAN_PLUS_VID method,
vs the  DEV_PLUS_VID method. For example, we add vlan 300 to eth3. Our configuration looks like this:

   interfaces {
        interface eth3 {
            vif "eth3.300" {
                disable: false
                vlan {
                    vlan-id: 300
                }
                address 3.3.3.3 {
                    prefix-length: 24
                    disable: false
                }
            }
        }
    }

So I would expect to see an interface eth3.300 in /proc/net/vlan, but instead it creates a file

/proc/net/vlan/vlan300

The file looks lke this:

eth3.300  VID: 300       REORDER_HDR: 1  dev->priv_flags: 1
         total frames received            0
          total bytes received            0
      Broadcast/Multicast Rcvd            0

      total frames transmitted            0
       total bytes transmitted            0
            total headroom inc            0
           total encap on xmit            0
Device: eth3
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
EGRESSS priority Mappings:

And or vlan config (/proc/net/vlan/config) has a type:

asterisk:/proc/net/vlan# cat config
VLAN Dev name    | VLAN ID
Name-Type: VLAN_NAME_TYPE_PLUS_VID_NO_PAD
eth3.300       | 300  | eth3

Yet, it DOES put an entry in /proc/net/dev for eth3.300 and NOT vlan300

eth3.300:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0

And it DOES create an interface for eth3.300:

eth3.300  Link encap:Ethernet  HWaddr 00:30:48:BD:29:99
          BROADCAST MULTICAST  MTU:1500  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)

And last but not least, it spits this information to the log:

[ 2011/02/11 11:08:16.627330  ERROR xorp_fea:6610 FEA fea/data_plane/ifconfig/ifconfig_set.cc:661 push_vif_address ] Failed to configure address because of device not found:
IfConfigSetNetlinkSocket::add_addr: check_nl_req: Cannot add address '3.3.3.3' on interface 'eth3' vif 'eth3.300': AF_NETLINK NLMSG_ERROR message: No such device

Because the basic end result is, we do in fact have an eth3.300, but it did NOT put my IP address on it.

So I suspect that we have two problems.

1) It's setting the wrong vlan model/type when probing the vlan module and configuring it wrong in proc
2) I suspect when it's trying to add the IP address to eth3.300, it's trying to modify an interface vlan300 (but I have no proof)


I've only been looking at the source for the past few hours, so I don't have a good handle on how it works but If someone can point me into the right
direction to set the vlan type/model up to DEV_PLUS_VID and for NL to look at the appropriate device that would be wonderful!

-- Joe



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110211/fab82f09/attachment.html 

From greearb at candelatech.com  Fri Feb 11 10:48:58 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 11 Feb 2011 10:48:58 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
Message-ID: <4D55849A.3010601@candelatech.com>

On 02/11/2011 10:37 AM, Joe Coco wrote:
> Hello everyone,
>
>
>>Nope. It hasn't worked (with a linux kernel) since 1.6. I remember when
>>  I looked into the code I came away thinking it might have worked with
>>  freebsd kernels once upon a time...
>
> This may very well end up in the development list, but for now.
>
> The problem, the way I see it is, the code is set up to create VLAN's
> using the VLAN_PLUS_VID method,
>
> vs the DEV_PLUS_VID method. For example, we add vlan 300 to eth3. Our
> configuration looks like this:
>
> interfaces {
>
> interface eth3 {
>
> vif "eth3.300" {
>
> disable: false
>
> vlan {
>
> vlan-id: 300
>
> }
>
> address 3.3.3.3 {
>
> prefix-length: 24
>
> disable: false
>
> }
>
> }
>
> }
>
> }
>
> So I would expect to see an interface eth3.300 in /proc/net/vlan, but
> instead it creates a file
>
> /proc/net/vlan/vlan300
>
> The file looks lke this:
>
> eth3.300 VID: 300 REORDER_HDR: 1 dev->priv_flags: 1
>
> total frames received 0
>
> total bytes received 0
>
> Broadcast/Multicast Rcvd 0
>
> total frames transmitted 0
>
> total bytes transmitted 0
>
> total headroom inc 0
>
> total encap on xmit 0
>
> Device: eth3
>
> INGRESS priority mappings: 0:0 1:0 2:0 3:0 4:0 5:0 6:0 7:0
>
> EGRESSS priority Mappings:
>
> And or vlan config (/proc/net/vlan/config) has a type:
>
> asterisk:/proc/net/vlan# cat config
>
> VLAN Dev name | VLAN ID
>
> Name-Type: VLAN_NAME_TYPE_PLUS_VID_NO_PAD
>
> eth3.300 | 300 | eth3
>
> Yet, it DOES put an entry in /proc/net/dev for eth3.300 and NOT vlan300
>
> eth3.300: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>
> And it DOES create an interface for eth3.300:
>
> eth3.300 Link encap:Ethernet HWaddr 00:30:48:BD:29:99
>
> BROADCAST MULTICAST MTU:1500 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)
>
> And last but not least, it spits this information to the log:
>
> [ 2011/02/11 11:08:16.627330 ERROR xorp_fea:6610 FEA
> fea/data_plane/ifconfig/ifconfig_set.cc:661 push_vif_address ] Failed to
> configure address because of device not found:
>
> IfConfigSetNetlinkSocket::add_addr: check_nl_req: Cannot add address
> '3.3.3.3' on interface 'eth3' vif 'eth3.300': AF_NETLINK NLMSG_ERROR
> message: No such device
>
> Because the basic end result is, we do in fact have an eth3.300, but it
> did NOT put my IP address on it.
>
> So I suspect that we have two problems.
>
> 1) It's setting the wrong vlan model/type when probing the vlan module
> and configuring it wrong in proc
>
> 2) I suspect when it's trying to add the IP address to eth3.300, it's
> trying to modify an interface vlan300 (but I have no proof)
>
>
>
> I've only been looking at the source for the past few hours, so I don't
> have a good handle on how it works but If someone can point me into the
> right
>
> direction to set the vlan type/model up to DEV_PLUS_VID and for NL to
> look at the appropriate device that would be wonderful!

I'd grep around in the fea sub-directory.  Look for ioctl calls related to
VLANs.

I'll poke around later today if you don't find something sooner.

Thanks,
Ben

>
> -- Joe
>


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


From jcoco at meccorp.mec.edu  Fri Feb 11 11:30:12 2011
From: jcoco at meccorp.mec.edu (Joe Coco)
Date: Fri, 11 Feb 2011 14:30:12 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D55849A.3010601@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
Message-ID: <65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>

Hello,

> I'd grep around in the fea sub-directory.  Look for ioctl calls related to
> VLANs.

> I'll poke around later today if you don't find something sooner.

> Thanks,
> Ben


The first half of the problem is in ifconfig_vlan_set_linux.cc so I'm looking at that.

What I'm not familiar with is the functionality in ifconfig_set.cc to select the interface in which the attributes are being set.

Thanks!

-- Joe


From greearb at candelatech.com  Fri Feb 11 11:23:16 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 11 Feb 2011 11:23:16 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
Message-ID: <4D558CA4.4090301@candelatech.com>

On 02/11/2011 11:30 AM, Joe Coco wrote:
> Hello,
>
>> I'd grep around in the fea sub-directory.  Look for ioctl calls related to
>> VLANs.
>
>> I'll poke around later today if you don't find something sooner.
>
>> Thanks,
>> Ben
>
>
> The first half of the problem is in ifconfig_vlan_set_linux.cc so I'm looking at that.
>
> What I'm not familiar with is the functionality in ifconfig_set.cc to select the interface in which the attributes are being set.

I think if you fix the VLAN naming issue, everything else is likely to
start working...

Thanks,
Ben

>
> Thanks!
>
> -- Joe


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


From jcoco at meccorp.mec.edu  Fri Feb 11 11:53:26 2011
From: jcoco at meccorp.mec.edu (Joe Coco)
Date: Fri, 11 Feb 2011 14:53:26 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D558CA4.4090301@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
Message-ID: <65A6944974518C4B9C0E818727B559E9397F845F@mecexchange2007.meccorp.mec.edu>

Hi Ben,

> I think if you fix the VLAN naming issue, everything else is likely to
> start working...

> Thanks,
>Ben

Well, I did successfully fix the vlan naming, so now it set's the name type to dev.vid, and puts the appropriate entries in /proc/net/vlan/config, and creates the appropriate per interface files.

It still has the IP address problem. I suspect somewhere there is another reference to it as vlan.vid, but I don't quite understand this code.

error:
Failed to configure address because of device not found: IfConfigSetNetlinkSocket::add_addr:
check_nl_req: Cannot add address '1.1.1.1' on interface 'eth1' vif 'eth1.100': AF_NETLINK NLMSG_ERROR message: No such device

The printing of the error uses strings such as 'eth1.100' as the device, but since I don't know how NL works I don't know that it is the ACTUAL device it's polling/modifying. 


So now I'm stuck.

Thanks!

-- Joe


From greearb at candelatech.com  Fri Feb 11 11:52:51 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 11 Feb 2011 11:52:51 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <65A6944974518C4B9C0E818727B559E9397F845F@mecexchange2007.meccorp.mec.edu>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F845F@mecexchange2007.meccorp.mec.edu>
Message-ID: <4D559393.7070903@candelatech.com>

On 02/11/2011 11:53 AM, Joe Coco wrote:
> Hi Ben,
>
>> I think if you fix the VLAN naming issue, everything else is likely to
>> start working...
>
>> Thanks,
>> Ben
>
> Well, I did successfully fix the vlan naming, so now it set's the name type to dev.vid, and puts the appropriate entries in /proc/net/vlan/config, and creates the appropriate per interface files.
>
> It still has the IP address problem. I suspect somewhere there is another reference to it as vlan.vid, but I don't quite understand this code.
>
> error:
> Failed to configure address because of device not found: IfConfigSetNetlinkSocket::add_addr:
> check_nl_req: Cannot add address '1.1.1.1' on interface 'eth1' vif 'eth1.100': AF_NETLINK NLMSG_ERROR message: No such device
>
> The printing of the error uses strings such as 'eth1.100' as the device, but since I don't know how NL works I don't know that it is the ACTUAL device it's polling/modifying.

I don't think the code is going to like interface name != vif-name.  There seem to be
lots of assumptions that they are always the same.  Maybe it's time to rip out that
code once and for all, and just make everything a vif.

For this particular error, it might be using eth1's info (name, or perhaps if-index)
instead of eth1.100

It's also possible that there is a race and eth1.100 either isn't in the kernel yet, or
hasn't been discovered by xorp.

What version of xorp are you using?  Latest xorp.ct from git tree?

Thanks,
Ben

>
>
> So now I'm stuck.
>
> Thanks!
>
> -- Joe


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


From jcoco at meccorp.mec.edu  Fri Feb 11 12:34:36 2011
From: jcoco at meccorp.mec.edu (Joe Coco)
Date: Fri, 11 Feb 2011 15:34:36 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D559393.7070903@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F845F@mecexchange2007.meccorp.mec.edu>
	<4D559393.7070903@candelatech.com>
Message-ID: <65A6944974518C4B9C0E818727B559E9397F846F@mecexchange2007.meccorp.mec.edu>

Hi Ben,

Some responses inline.


> For this particular error, it might be using eth1's info (name, or perhaps if-index)
> instead of eth1.100

I was thinking that. Unfortunately, as I said before, I've not done much with netlink so I'm having
trouble understanding some of this code in the brief time I've looked at it. 


> It's also possible that there is a race and eth1.100 either isn't in the kernel yet, or
> hasn't been discovered by xorp.

I don't think that is it, see below, but I could be wrong.

> What version of xorp are you using?  Latest xorp.ct from git tree?

1.8.2b from Dec 8, 2010 https://github.com/greearb/xorp.ct/downloads

I uncommented some debugging print statements and added a few of my own so I could watch xorp 'step through it' when I hit commit:

(here is right after the commit)

end deltas
end deletions
[ 2011/02/11 14:34:36.857021  WARNING xorp_fea:7164 FEA fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc:330 nlm_cond_newlink_to_fea_cfg ] newlink, interface: eth0  tree: system-config
[ 2011/02/11 14:34:36.857060  WARNING xorp_fea:7164 FEA fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc:330 nlm_cond_newlink_to_fea_cfg ] newlink, interface: eth1  tree: system-config
[ 2011/02/11 14:34:36.857084  WARNING xorp_fea:7164 FEA fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc:330 nlm_cond_newlink_to_fea_cfg ] newlink, interface: eth2  tree: system-config
[ 2011/02/11 14:34:36.857107  WARNING xorp_fea:7164 FEA fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc:330 nlm_cond_newlink_to_fea_cfg ] newlink, interface: eth3  tree: system-config

-JC- Set name-type for VLAN

-JC- Created vlan device: eth1.100

[ 2011/02/11 14:34:36.860771  WARNING xorp_fea:7164 FEA fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc:330 nlm_cond_newlink_to_fea_cfg ] newlink, interface: eth0  tree: system-config
[ 2011/02/11 14:34:36.860822  WARNING xorp_fea:7164 FEA fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc:330 nlm_cond_newlink_to_fea_cfg ] newlink, interface: eth1  tree: system-config
[ 2011/02/11 14:34:36.860868  WARNING xorp_fea:7164 FEA fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc:330 nlm_cond_newlink_to_fea_cfg ] newlink, interface: eth1.100  tree: system-config
[ 2011/02/11 14:34:36.860899  WARNING xorp_fea:7164 FEA fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc:330 nlm_cond_newlink_to_fea_cfg ] newlink, interface: eth2  tree: system-config
[ 2011/02/11 14:34:36.860940  WARNING xorp_fea:7164 FEA fea/data_plane/ifconfig/ifconfig_parse_netlink_socket.cc:330 nlm_cond_newlink_to_fea_cfg ] newlink, interface: eth3  tree: system-config
[ 2011/02/11 14:34:36.861113  ERROR xorp_fea:7164 FEA fea/data_plane/ifconfig/ifconfig_set.cc:661 push_vif_address ] Failed to configure address because of device not found: IfConfigSetNetlinkSocket::add_addr: check_nl_req: $


So it appears it does in fact see the eth1.100 interface prior to trying to push the vif address. 



Thanks!

-- Joe


From jcoco at meccorp.mec.edu  Mon Feb 14 07:15:04 2011
From: jcoco at meccorp.mec.edu (Joe Coco)
Date: Mon, 14 Feb 2011 10:15:04 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D558CA4.4090301@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
Message-ID: <65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>

Hello,

I think I've pretty much tracked it well in fea/ and from what I can tell, the ifname and vifnames all look good, it doesn't appear to be making any reference to the wrong device. I cannot figure what 'device' is 'not found' in netlink. I'm really stumped on this one..

(log with my added prints)

-JC- add_addr called with  ifname: eth1
-JC- add_addr called with vifname: eth1.100
-JC- push_vif_address - config_iface ifname: eth1
-JC- push_vif_address - config_vif vifname: eth1.100
[ 2011/02/14 10:01:17.770439  ERROR xorp_fea:10098 FEA fea/data_plane/ifconfig/ifconfig_set.cc:668 push_vif_address ] Failed to configure address because of device not found: IfConfigSetNetlinkSocket::add_addr: check_nl_req: Cannot add address '1.1.1.1' on interface 'eth1' vif 'eth1.100': AF_NETLINK NLMSG_ERROR message: No such device



From greearb at candelatech.com  Mon Feb 14 07:36:57 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 14 Feb 2011 07:36:57 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
Message-ID: <4D594C19.4010504@candelatech.com>

On 02/14/2011 07:15 AM, Joe Coco wrote:
> Hello,
>
> I think I've pretty much tracked it well in fea/ and from what I can tell, the ifname and vifnames all look good, it doesn't appear to be making any reference to the wrong device. I cannot figure what 'device' is 'not found' in netlink. I'm really stumped on this one..
>
> (log with my added prints)
>
> -JC- add_addr called with  ifname: eth1
> -JC- add_addr called with vifname: eth1.100
> -JC- push_vif_address - config_iface ifname: eth1
> -JC- push_vif_address - config_vif vifname: eth1.100
> [ 2011/02/14 10:01:17.770439  ERROR xorp_fea:10098 FEA fea/data_plane/ifconfig/ifconfig_set.cc:668 push_vif_address ] Failed to configure address because of device not found: IfConfigSetNetlinkSocket::add_addr: check_nl_req: Cannot add address '1.1.1.1' on interface 'eth1' vif 'eth1.100': AF_NETLINK NLMSG_ERROR message: No such device

Please post your current patch, and the simplest xorp-config test case that
you can think of.  I should have time to look at this today if all goes
as planned.

Thanks,
Ben

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


From jcoco at meccorp.mec.edu  Mon Feb 14 08:15:54 2011
From: jcoco at meccorp.mec.edu (Joe Coco)
Date: Mon, 14 Feb 2011 11:15:54 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D594C19.4010504@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
Message-ID: <65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>

Hello,


> Please post your current patch, and the simplest xorp-config test case that
> you can think of.  I should have time to look at this today if all goes
> as planned.
>
>Thanks,
>Ben



Ok. It's mainly some printing for debug. I commented out where it initializes vlan type until I can make a proper fix as you can see so we can do traditional dev.vlan. I.e, google searchers don't even think of applying this it's _WRONG_. 
 


Config:

   interfaces {
        interface eth1 {
            vif "eth1.100" {
                disable: false
                vlan {
                    vlan-id: 100
                }
                address 1.1.1.1 {
                    prefix-length: 24
                    disable: false
                }
            }
        }
    }


Step by step of config:

# create interfaces interface eth1 disable false
# create interfaces interface eth1 vif eth1.100 vlan vlan-id 100
# create interfaces interface eth1 vif eth1.100 address 1.1.1.1 prefix-length 24
# commit


ugly patch:

--- fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc-orig 2010-12-08 15:12:48.000000000 -0500
+++ fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc      2011-02-14 10:52:11.000000000 -0500
@@ -985,6 +985,12 @@

     memset(&buffer, 0, sizeof(buffer));

+/* Just to make sure nothing got lost or fouled up. This should print dev, followed by dev.vlan */
+
+fprintf(stderr, "-JC- add_addr called with  ifname: %s\n", ifname.c_str());
+fprintf(stderr, "-JC- add_addr called with vifname: %s\n", vifname.c_str());
+
+
     // Set the socket
     memset(&snl, 0, sizeof(snl));
     snl.nl_family = AF_NETLINK;
--- fea/data_plane/ifconfig/ifconfig_vlan_set_linux.cc-orig     2010-12-08 15:12:48.000000000 -0500
+++ fea/data_plane/ifconfig/ifconfig_vlan_set_linux.cc  2011-02-14 10:51:06.000000000 -0500
@@ -200,19 +200,27 @@
 {
     struct vlan_ioctl_args vlanreq;

+char tmpsystem[32];
+
     //
     // Set the VLAN interface naming
     //
-    memset(&vlanreq, 0, sizeof(vlanreq));
-    vlanreq.u.name_type = VLAN_NAME_TYPE_PLUS_VID_NO_PAD;      // vlan10
-    vlanreq.cmd = SET_VLAN_NAME_TYPE_CMD;
-    if (ioctl(_s4, SIOCSIFVLAN, &vlanreq) < 0) {
-       error_msg = c_format("Cannot set the VLAN interface name type"
-                            "to %s: %s",
-                            "VLAN_NAME_TYPE_PLUS_VID_NO_PAD",
-                            strerror(errno));
-       return (XORP_ERROR);
-    }
+//    memset(&vlanreq, 0, sizeof(vlanreq));
+//    vlanreq.u.name_type = DEV_PLUS_VID; /* eth1.100 */
+//    vlanreq.cmd = SET_VLAN_NAME_TYPE_CMD;
+//    if (ioctl(_s4, SIOCSIFVLAN, &vlanreq) < 0) {
+//     error_msg = c_format("Cannot set the VLAN interface name type"
+//                          "to %s: %s",
+//                          "VLAN_NAME_TYPE_PLUS_VID_NO_PAD",
+//                          strerror(errno));
+//     return (XORP_ERROR);
+  //  }
+
+/* This is a temporary hack/joke. Really, for now just use Ben's vconfig with the intention of fixing
+   the above code to be dev_plus_vif like most linux (other than zebos) - JC */
+
+system("/sbin/vconfig set_name_type DEV_PLUS_VID_NO_PAD");
+

     //
     // Create the VLAN
@@ -229,10 +237,18 @@
        return (XORP_ERROR);
     }

+fprintf(stderr, "-JC- Created vlan device: %s \n", vlan_name.c_str()); /* -JC */
+
     //
     // Rename the VLAN interface if necessary
     //
-    string tmp_vlan_name = c_format("vlan%u", vlan_id);
+//    string tmp_vlan_name = c_format("vlan%u", vlan_id);
+
+  string tmp_vlan_name = vlan_name.c_str();
+
+
+//c_format("%s.%u", parent_ifname.c_str(), vlan_id);
+

     if (vlan_name != tmp_vlan_name) {
 #ifndef SIOCSIFNAME
--- fea/data_plane/ifconfig/ifconfig_set.cc-orig        2010-12-08 15:12:48.000000000 -0500
+++ fea/data_plane/ifconfig/ifconfig_set.cc     2011-02-14 10:47:47.000000000 -0500
@@ -656,6 +656,10 @@
                               config_iface, config_vif, config_addr,
                               error_msg)
            != XORP_OK) {
+
+               fprintf(stderr, "-JC- push_vif_address - config_iface ifname: %s\n", config_iface.ifname().c_str());
+               fprintf(stderr, "-JC- push_vif_address - config_vif vifname: %s\n", config_vif.vifname().c_str());
+
            if (strstr(error_msg.c_str(), "No such device")) {
                XLOG_ERROR("Failed to configure address because of device not found: %s",
                           error_msg.c_str());




From Leo.Grinberg at iqor.com  Mon Feb 14 09:14:11 2011
From: Leo.Grinberg at iqor.com (Grinberg, Leo)
Date: Mon, 14 Feb 2011 12:14:11 -0500
Subject: [Xorp-users] Error while running Xorp on Windows Server 2008
In-Reply-To: <80C343A5D090C24F9229C34CCD1728740583008E@usnjpar1blex05.us.ad.irmc.com>
References: <80C343A5D090C24F9229C34CCD1728740583008E@usnjpar1blex05.us.ad.irmc.com>
Message-ID: <80C343A5D090C24F9229C34CCD17287405830091@usnjpar1blex05.us.ad.irmc.com>

 

 

Leo Grinberg

Network Engineering

iQor

973-294-7021 (O)

646-320-2544 (C)

 

From: Grinberg, Leo 
Sent: Monday, February 14, 2011 11:59 AM
To: xorp-users at xorp.org
Subject: Error while running Xorp on Windows Server 2008

 

 

I am trying to get rtrmgr to run.  The system is Windows Server 2008.
When I run the rtrmgr, the fea process dies and before it does so I get
the following warning and error.

WARNING C:\XORP\fea\xorp_fea.exe FEA ] Route via unknown interface index
13

FATAL c:\XORP\fea\xorp_fea.exe:2056 FEA +314
fibconfig_entry_set_iphelper.cc delete_entry ] Assertion (vifp != NULL)
failed

 

I have  the interface and vif configured as "Local Area Connection 2"
which is what shows up (naturally) when I do 'ipconfig' on my windows
machine from the command prompt.   I suspect the XORP is not able to
match the interface in the config file to the interface name on the
operating system.  Is that the case and what is the solution for this?
A bigger question:  is XORP supported on Windows 2008?

 

 

 

Leo Grinberg

Network Engineering

iQor

973-294-7021 (O)

646-320-2544 (C)

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110214/9702c911/attachment.html 

From greearb at candelatech.com  Mon Feb 14 09:31:05 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 14 Feb 2011 09:31:05 -0800
Subject: [Xorp-users] Error while running Xorp on Windows Server 2008
In-Reply-To: <80C343A5D090C24F9229C34CCD17287405830091@usnjpar1blex05.us.ad.irmc.com>
References: <80C343A5D090C24F9229C34CCD1728740583008E@usnjpar1blex05.us.ad.irmc.com>
	<80C343A5D090C24F9229C34CCD17287405830091@usnjpar1blex05.us.ad.irmc.com>
Message-ID: <4D5966D9.2030609@candelatech.com>

On 02/14/2011 09:14 AM, Grinberg, Leo wrote:
> Leo Grinberg
>
> Network Engineering
>
> iQor
>
> 973-294-7021 (O)
>
> 646-320-2544 (C)
>
> *From:* Grinberg, Leo
> *Sent:* Monday, February 14, 2011 11:59 AM
> *To:* xorp-users at xorp.org
> *Subject:* Error while running Xorp on Windows Server 2008
>
> I am trying to get rtrmgr to run. The system is Windows Server 2008.
> When I run the rtrmgr, the fea process dies and before it does so I get
> the following warning and error.
>
> WARNING C:\XORP\fea\xorp_fea.exe FEA ] Route via unknown interface index 13
>
> FATAL c:\XORP\fea\xorp_fea.exe:2056 FEA +314
> fibconfig_entry_set_iphelper.cc delete_entry ] Assertion (vifp != NULL)
> failed
>
> I have the interface and vif configured as ?Local Area Connection 2?
> which is what shows up (naturally) when I do ?ipconfig? on my windows
> machine from the command prompt. I suspect the XORP is not able to match
> the interface in the config file to the interface name on the operating
> system. Is that the case and what is the solution for this? A bigger
> question: is XORP supported on Windows 2008?

I'm not sure if it has worked previously to version 1.6, but in later
releases windows support was removed entirely.  If someone wants
to send patches against the latest xorp.ct to re-enable Windows
support, I'll consider applying them..but I have no interest in
working on it myself.

Linux and BSD are well supported, but I only develop on Linux, so I
suggest that if you are able...

Thanks,
Ben

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


From sandeep.sharma2 at iqor.com  Mon Feb 14 09:45:35 2011
From: sandeep.sharma2 at iqor.com (Sharma2, Sandeep)
Date: Mon, 14 Feb 2011 12:45:35 -0500
Subject: [Xorp-users] XORP on Windows
Message-ID: <3554AFFDD1D9B842BD71DCA70CF35CB8011B017A@usnjpar1blex05.us.ad.irmc.com>

 

Hi,

 

I am trying to run XORP 1.6 on multiple platforms. I was able to get it
to run quite easily on Centos Linux 2.6.18 but ran into difficulties on
Windows Server 2008. I could not figure out the correct way to name the
network interfaces in the boot config file. Unfortunately I could not
get show_interfaces to run either.

 

Unsuccessfully tried:

Unix style interface names e.g. eth0 and ge0

Windows ipconfig syle interface names e.g. "Local Area Connection 2"

 

Can anyone point out the correct naming scheme for network interfaces on
Windows ?

 

Thanks,

Sandeep

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110214/7d5c174d/attachment-0001.html 

From greearb at candelatech.com  Mon Feb 14 12:23:55 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 14 Feb 2011 12:23:55 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
Message-ID: <4D598F5B.1000405@candelatech.com>

On 02/14/2011 08:15 AM, Joe Coco wrote:
> Hello,
>
>
>> Please post your current patch, and the simplest xorp-config test case that
>> you can think of.  I should have time to look at this today if all goes
>> as planned.
>>
>> Thanks,
>> Ben
>
>
>
> Ok. It's mainly some printing for debug. I commented out where it initializes vlan type until I can make a proper fix as you can see so we can do traditional dev.vlan. I.e, google searchers don't even think of applying this it's _WRONG_.

Thanks for the useful test case.

I found some of the problems:

First, I fixed the vlan naming to use "eth1.5" format.

But, that doesn't really fix the problem because xorp uses 'pif-index',
ie physical port ifindex when it really should be using the ifindex of
the VIF.

I added two hacks to work around this for ip addr add/delete (on Linux),
but the code to make the interface admin-UP is still broken (I'm sure
it's using the ifindex of the parent, which does nothing useful to the
VLAN, though it returns no errors).

Fixing this proper is probably going to require quite a bit of code
change to fix some bad assumptions about VIFS v/s Interfaces.

I'll go ahead and push my 'fixes' now..but be aware they do not fix
the entire problem.  I'll start poking at more substantial changes,
but not sure when I'll get it done.

Thanks,
Ben


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


From jcoco at meccorp.mec.edu  Mon Feb 14 12:52:36 2011
From: jcoco at meccorp.mec.edu (Joe Coco)
Date: Mon, 14 Feb 2011 15:52:36 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D598F5B.1000405@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
Message-ID: <65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>


> Thanks for the useful test case.

> I found some of the problems:

> First, I fixed the vlan naming to use "eth1.5" format.

Was that simply a change from:

-    vlanreq.u.name_type = VLAN_NAME_TYPE_PLUS_VID_NO_PAD;      // vlan10
+    vlanreq.u.name_type = VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD; /* eth1.100 */

in  fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc  ?


That is all I changed on mine, and it appeared to fix the entries in /proc/net/vlan/

> But, that doesn't really fix the problem because xorp uses 'pif-index',
> ie physical port ifindex when it really should be using the ifindex of
> the VIF.

> I added two hacks to work around this for ip addr add/delete (on Linux),
> but the code to make the interface admin-UP is still broken (I'm sure
> it's using the ifindex of the parent, which does nothing useful to the
> VLAN, though it returns no errors).

> Fixing this proper is probably going to require quite a bit of code
> change to fix some bad assumptions about VIFS v/s Interfaces.

> I'll go ahead and push my 'fixes' now..but be aware they do not fix
> the entire problem.  I'll start poking at more substantial changes,
> but not sure when I'll get it done.

Thanks for taking the time to look at it. Do you think you could email me your patch
so I can see what you started on and maybe hack at it a little bit?

-- Joe


From greearb at candelatech.com  Mon Feb 14 12:45:22 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 14 Feb 2011 12:45:22 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>
Message-ID: <4D599462.5050809@candelatech.com>

On 02/14/2011 12:52 PM, Joe Coco wrote:
>
>> Thanks for the useful test case.
>
>> I found some of the problems:
>
>> First, I fixed the vlan naming to use "eth1.5" format.
>
> Was that simply a change from:
>
> -    vlanreq.u.name_type = VLAN_NAME_TYPE_PLUS_VID_NO_PAD;      // vlan10
> +    vlanreq.u.name_type = VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD; /* eth1.100 */
>
> in  fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc  ?
>
>
> That is all I changed on mine, and it appeared to fix the entries in /proc/net/vlan/
>
>> But, that doesn't really fix the problem because xorp uses 'pif-index',
>> ie physical port ifindex when it really should be using the ifindex of
>> the VIF.
>
>> I added two hacks to work around this for ip addr add/delete (on Linux),
>> but the code to make the interface admin-UP is still broken (I'm sure
>> it's using the ifindex of the parent, which does nothing useful to the
>> VLAN, though it returns no errors).
>
>> Fixing this proper is probably going to require quite a bit of code
>> change to fix some bad assumptions about VIFS v/s Interfaces.
>
>> I'll go ahead and push my 'fixes' now..but be aware they do not fix
>> the entire problem.  I'll start poking at more substantial changes,
>> but not sure when I'll get it done.
>
> Thanks for taking the time to look at it. Do you think you could email me your patch
> so I can see what you started on and maybe hack at it a little bit?

It's pushed to xorp.ct, just 'git pull', or check out a new one if you have been
using a static snapshot (and git pull in the future)...

'gitk' is useful for viewing patches, etc.

Also, the VIF handling doesn't look quite so broken now that
I look a bit more...maybe the problem is just that the system
hasn't managed to probe the physical index yet, or something
like that...poking at that after lunch.

Thanks,
Ben

>
> -- Joe


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


From greearb at candelatech.com  Mon Feb 14 14:18:06 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 14 Feb 2011 14:18:06 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>
Message-ID: <4D59AA1E.7000608@candelatech.com>

On 02/14/2011 12:52 PM, Joe Coco wrote:
>
>> Thanks for the useful test case.
>
>> I found some of the problems:
>
>> First, I fixed the vlan naming to use "eth1.5" format.
>
> Was that simply a change from:
>
> -    vlanreq.u.name_type = VLAN_NAME_TYPE_PLUS_VID_NO_PAD;      // vlan10
> +    vlanreq.u.name_type = VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD; /* eth1.100 */
>
> in  fea/data_plane/ifconfig/ifconfig_set_netlink_socket.cc  ?

After some more looking, I think using VLANs as VIFS like this is not
worth the effort.  We'd have to do some hard-core hacking on
the vif class...basically re-implement all or most of the Interface
logic.

And even that doesn't really scale..because you can have vlans on vlans, macvlans,
bridge devices and various other stacking.

So, I think I'd propose that virtual interfaces be created outside of xorp.
Please note that xorp.ct *should* work fine if you start it before the
VLANs are created, and then create them sometime later.  It should also
deal with dynamically adding/deleting interface config from within
xorpsh, independently of the coming and going of interfaces in the
OS.  (I put a lot of effort into this for our WISER product, but
problems could remain..so yell if you find bugs of this nature.)

If someone has a use case that would be difficult in this scenario,
please post to the list...

Thanks,
Ben

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


From jcoco at meccorp.mec.edu  Mon Feb 14 14:46:08 2011
From: jcoco at meccorp.mec.edu (Joe Coco)
Date: Mon, 14 Feb 2011 17:46:08 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D59AA1E.7000608@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>,
	<4D59AA1E.7000608@candelatech.com>
Message-ID: <65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>


> After some more looking, I think using VLANs as VIFS like this is not
> worth the effort.  We'd have to do some hard-core hacking on
> the vif class...basically re-implement all or most of the Interface
> logic.

> And even that doesn't really scale..because you can have vlans on vlans, macvlans,
> bridge devices and various other stacking.

> So, I think I'd propose that virtual interfaces be created outside of xorp.
> Please note that xorp.ct *should* work fine if you start it before the
> VLANs are created, and then create them sometime later.  It should also
> deal with dynamically adding/deleting interface config from within
> xorpsh, independently of the coming and going of interfaces in the
> OS.  (I put a lot of effort into this for our WISER product, but
>problems could remain..so yell if you find bugs of this nature.)

Well, you can very well create all your vlan interfaces before starting xorpsh, and that does in fact work. 

What I was trying to do was create vlans from within xorp, which absolutely does not work. 

For a lot of folks, configuring the interfaces OS side then running xorp would be fine, but my test case was seeing if xorp could serve as a replacement
for ZebOS in a routing appliance. (i.e, xorpsh ONLY). 

Any suggestions? 

-- Joe



From greearb at candelatech.com  Mon Feb 14 14:41:14 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 14 Feb 2011 14:41:14 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>,
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>
Message-ID: <4D59AF8A.4040502@candelatech.com>

On 02/14/2011 02:46 PM, Joe Coco wrote:
>
>> After some more looking, I think using VLANs as VIFS like this is not
>> worth the effort.  We'd have to do some hard-core hacking on
>> the vif class...basically re-implement all or most of the Interface
>> logic.
>
>> And even that doesn't really scale..because you can have vlans on vlans, macvlans,
>> bridge devices and various other stacking.
>
>> So, I think I'd propose that virtual interfaces be created outside of xorp.
>> Please note that xorp.ct *should* work fine if you start it before the
>> VLANs are created, and then create them sometime later.  It should also
>> deal with dynamically adding/deleting interface config from within
>> xorpsh, independently of the coming and going of interfaces in the
>> OS.  (I put a lot of effort into this for our WISER product, but
>> problems could remain..so yell if you find bugs of this nature.)
>
> Well, you can very well create all your vlan interfaces before starting xorpsh, and that does in fact work.
>
> What I was trying to do was create vlans from within xorp, which absolutely does not work.
>
> For a lot of folks, configuring the interfaces OS side then running xorp would be fine, but my test case was seeing if xorp could serve as a replacement
> for ZebOS in a routing appliance. (i.e, xorpsh ONLY).

Any reason you can't add 'vconfig', or use a moderately up-to-date 'ip' tool to
create the VLANs before you log into xorpsh?

Thanks,
Ben

>
> Any suggestions?
>
> -- Joe


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


From jcoco at meccorp.mec.edu  Mon Feb 14 14:56:00 2011
From: jcoco at meccorp.mec.edu (Joe Coco)
Date: Mon, 14 Feb 2011 17:56:00 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D59AF8A.4040502@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>,
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>,
	<4D59AF8A.4040502@candelatech.com>
Message-ID: <65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>


> Any reason you can't add 'vconfig', or use a moderately up-to-date 'ip' tool to
> create the VLANs before you log into xorpsh?

You can. 

However in a working environment, like metro ethernet for example. If you are using xorp as a router and you are adding and removing vlans non stop it's better to have a single
configuration interface rather than to have to have a network admin 'shell out' to use vconfig, then go into xorpsh to configure routes or dynamic routing protocols. 

Like I said, I'm experimenting with xorp to replace ZebOS as the routing engine for router appliances. The idea is a router like CLI only, and hide the unix. ZebOS as
you know is cisco-like, where xorp is Juniper. so they both fit in with the network guys very well. 

Thanks!

-- Joe


From greearb at candelatech.com  Mon Feb 14 15:03:19 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 14 Feb 2011 15:03:19 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>,
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>,
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
Message-ID: <4D59B4B7.7060603@candelatech.com>

On 02/14/2011 02:56 PM, Joe Coco wrote:
>
>> Any reason you can't add 'vconfig', or use a moderately up-to-date 'ip' tool to
>> create the VLANs before you log into xorpsh?
>
> You can.
>
> However in a working environment, like metro ethernet for example. If you are using xorp as a router and you are adding and removing vlans non stop it's better to have a single
> configuration interface rather than to have to have a network admin 'shell out' to use vconfig, then go into xorpsh to configure routes or dynamic routing protocols.
>
> Like I said, I'm experimenting with xorp to replace ZebOS as the routing engine for router appliances. The idea is a router like CLI only, and hide the unix. ZebOS as
> you know is cisco-like, where xorp is Juniper. so they both fit in with the network guys very well.

Ok.  I'm pretty sure we'll never support VLANs as sub-interfaces of real interfaces
properly (at least if I'm writing the code), but we could probably make one able to create
a proper interface that is a VLAN through the xorp config file (and/or xorpsh)

If you ever wanted to get clever and stack vlans, that might get interesting to implement
though...

Thanks,
Ben

>
> Thanks!
>
> -- Joe


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


From jcoco at meccorp.mec.edu  Mon Feb 14 16:29:17 2011
From: jcoco at meccorp.mec.edu (Joe Coco)
Date: Mon, 14 Feb 2011 19:29:17 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D59B4B7.7060603@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>,
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>,
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>,
	<4D59B4B7.7060603@candelatech.com>
Message-ID: <65A6944974518C4B9C0E818727B559E939357C25@mecexchange2007.meccorp.mec.edu>


Hi Ben,

> Ok.  I'm pretty sure we'll never support VLANs as sub-interfaces of real interfaces
> properly (at least if I'm writing the code), but we could probably make one able to create
> a proper interface that is a VLAN through the xorp config file (and/or xorpsh)

> If you ever wanted to get clever and stack vlans, that might get interesting to implement
> though...

There is nothing essentially wrong with the vlanxxxx method, it just doesn't work either in xorp 1.8.2b.

Unless I'm mistaken. I tried it that way, then tried making it work with the dev.vid method. 

Worst case scenario, I can hack it to work the way I was trying I just was hoping to get something
usable for the community in general, not just me. 

-- Joe


From greearb at candelatech.com  Mon Feb 14 16:57:24 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 14 Feb 2011 16:57:24 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <65A6944974518C4B9C0E818727B559E939357C25@mecexchange2007.meccorp.mec.edu>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>,
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>,
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>,
	<4D59B4B7.7060603@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C25@mecexchange2007.meccorp.mec.edu>
Message-ID: <4D59CF74.50405@candelatech.com>

On 02/14/2011 04:29 PM, Joe Coco wrote:
>
> Hi Ben,
>
>> Ok.  I'm pretty sure we'll never support VLANs as sub-interfaces of real interfaces
>> properly (at least if I'm writing the code), but we could probably make one able to create
>> a proper interface that is a VLAN through the xorp config file (and/or xorpsh)
>
>> If you ever wanted to get clever and stack vlans, that might get interesting to implement
>> though...
>
> There is nothing essentially wrong with the vlanxxxx method, it just doesn't work either in xorp 1.8.2b.
>
> Unless I'm mistaken. I tried it that way, then tried making it work with the dev.vid method.

The naming isn't the real problem.  Xorp had code to rename it without the
work that I did..and it looks like it probably worked right.  I think the
eth0.5 method is likely to work a bit better...because that doesn't clash
with eth1.5.

>
> Worst case scenario, I can hack it to work the way I was trying I just was hoping to get something
> usable for the community in general, not just me.

 From what I can tell, you are going to run into endless hard-to-debug
problems with nested VLANs in the current code.  A trivial example is
that a VLAN can have (and usually should have) a different MAC than
it's parent device.  There is currently no where to store that,
and the code just assumes that VIFS don't have macs, or link state,
etc.  So, any code that pays attention to the MAC is going to be
subtly broken.

I think the way to go is to have some new attributes to
interfaces, maybe something like:

    interfaces {
         interface eth1.100 {
             type: 8021q-vlan
             vlan-id: 100
             parent-dev: eth1
             vif "eth1.100" {
                 disable: false
                 address 1.1.1.1 {
                     prefix-length: 24
                     disable: false
                 }
             }
         }
     }


We'd need extra code to deal with those new variables, and code to create
the interface (similar to how it does now) as soon as we discover the parent-dev.

That parent-dev thing could be iterative to allow multiple nestings of
VLANs, bridges, etc.

Other types (when someone cares enough to implement them) could be:

mac-vlan
bridge

Maybe wireless stations, APs, etc...

I have basically implemented this sort of thing in our LANforge product..it's
not super easy to get right, and lots of special cases for each virtual device type, but
neither is it overly difficult.

Thanks,
Ben


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


From Leo.Grinberg at iqor.com  Mon Feb 14 14:10:43 2011
From: Leo.Grinberg at iqor.com (Grinberg, Leo)
Date: Mon, 14 Feb 2011 17:10:43 -0500
Subject: [Xorp-users] OSPF neighbors not establishing with a Cisco router
Message-ID: <80C343A5D090C24F9229C34CCD172874058300E3@usnjpar1blex05.us.ad.irmc.com>

Hi, I have XORP 1.6 running on CentOS Linux 2.6.18 and connected via
Ethernet to a Cisco 3845 router.  Both routers are configured to use
OSPF in Area 0.

Both send Hello's to 224.0.0.5.  The Cisco router processes the Hello
from the XORP box and sends a Hello directly to it.  However the XORP
box ignores it,  it seems to me that it is not even processing the Hello
sent by the Cisco router to the multicast IP.

Why is the XORP router not processing the multicast hello's?

 

Here is the pertinent information:

Show ospf neighbors from Cisco router:

 

Qrouter#show ip ospf nei

 

Neighbor ID     Pri   State           Dead Time   Address
Interface

10.2.46.180     128   INIT/DROTHER    00:00:30    10.2.46.180
GigabitEthernet0/0

Qrouter#

 

 

Debug from the Cisco router:

 

*Feb 14 22:15:14.694: OSPF: Send hello to 224.0.0.5 area 0 on
GigabitEthernet0/0 from 10.2.46.2

*Feb 14 22:15:22.274: OSPF: Rcv hello from 10.2.46.180 area 0 from
GigabitEthernet0/0 10.2.46.180

*Feb 14 22:15:22.274: OSPF: Send immediate hello to nbr 10.2.46.180, src
address 10.2.46.180, on GigabitEthernet0/0

*Feb 14 22:15:22.274: OSPF: Send hello to 10.2.46.180 area 0 on
GigabitEthernet0/0 from 10.2.46.2

*Feb 14 22:15:22.274: OSPF: End of hello processing

 

Show ospf neighbors from XORP router (also the capture is attached as
ospf2.pcap).

 

root at localhost.localdomain> show ospf4 neighbor 

  Address         Interface             State      ID              Pri
Dead

root at localhost.localdomain> quit

 

TCPDUMP from the XORP router:

[root at localhost Administrator]# /usr/sbin/tcpdump -i eth1 proto ospf 

tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode

listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes

17:08:55.058523 IP 10.2.46.2 > ospf-all.mcast.net: OSPFv2, Hello,
length: 60

17:09:02.633499 IP 10.2.46.180 > ospf-all.mcast.net: OSPFv2, Hello,
length: 44

17:09:02.633978 IP 10.2.46.2 > 10.2.46.180: OSPFv2, Hello, length: 60

17:09:05.058747 IP 10.2.46.2 > ospf-all.mcast.net: OSPFv2, Hello,
length: 60

 

Config file of the XORP router

 

interfaces {

    restore-original-config-on-shutdown: false

    interface eth1 {

        description: "data interface"

        disable: false

        /* default-system-config */

        vif eth1 {

            disable: false

            address 10.2.46.180 {

                prefix-length: 24

                broadcast: 10.2.46.255

                disable: false

            }

        }

    }

    interface eth2 {

        vif eth2 {

            disable false

            address 10.4.46.180 {

                prefix-length 24

                broadcast: 10.4.46.255

                disable false

            }

        }

    }

}

 

fea {

    unicast-forwarding4 {

        disable: false

    }

}

 

    {

                broadcast: 10.4.46.255

                disable false

            }

        }

    }

}

 

fea {

    unicast-forwarding4 {

        disable: false

    }

    multicast-forwarding4 {

        disable: false

    }

}

 

protocols {

    ospf4 {

        router-id: 10.2.46.180

 

        area 0.0.0.0 {

            interface eth1 {

                vif eth1      {

"config4.boot" 71L, 1003C written

[root at localhost etc]# vi config4.boot 

 

/* 10.140.14.23/home/Administrator/xorp/xorp-1.6 */

 

interfaces {

    restore-original-config-on-shutdown: false

    interface eth1 {

        description: "data interface"

        disable: false

        /* default-system-config */

        vif eth1 {

            disable: false

            address 10.2.46.180 {

                prefix-length: 24

                broadcast: 10.2.46.255

                disable: false

            }

        }

    }

    interface eth2 {

        vif eth2 {

            disable false

            address 10.4.46.180 {

                prefix-length 24

                broadcast: 10.4.46.255

                disable false

            }

        }

    }

}

 

fea {

    unicast-forwarding4 {

        disable: false

    }

    multicast-forwarding4 {

        disable: false

    }

}

 

protocols {

    ospf4 {

        router-id: 10.2.46.180

 

        area 0.0.0.0 {

            interface eth1 {

                vif eth1      {

                    address 10.2.46.180 {

                    }

                }

    multicast-forwarding4 {

        disable: false

    }

            }

        }

    }

}

 

fea {

    unicast-forwarding4 {

        disable: false

    }

}

plumbing {

        mfea4 {

                disable: false

                interface eth1 {

                        vif eth1 {

                                disable: false

                        }

                }

        }

}

 

protocols {

    ospf4 {

        router-id: 10.2.46.180

 

        area 0.0.0.0 {

            interface eth1 {

                vif eth1      {

                    address 10.2.46.180 {

                    }

                }

            }

        }

 

        area 10.4.46.0 {

            area-type stub

 

            area-range 10.4.46.0/24 {

                advertise true

            }

 

            default-lsa {

                metric 10

            }

 

            interface eth2 {

                vif eth2 {

                    address 10.4.46.180 {

                    }

                }

            }

        }

    }

 

Leo Grinberg

Network Engineering

iQor

973-294-7021 (O)

646-320-2544 (C)

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110214/60e8a387/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ospf2.pcap
Type: application/octet-stream
Size: 9758 bytes
Desc: ospf2.pcap
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110214/60e8a387/attachment-0001.obj 

From jcoco at meccorp.mec.edu  Tue Feb 15 11:32:18 2011
From: jcoco at meccorp.mec.edu (Joe Coco)
Date: Tue, 15 Feb 2011 14:32:18 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D59B4B7.7060603@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>,
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>,
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
	<4D59B4B7.7060603@candelatech.com>
Message-ID: <65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>

Hello,

I found another problem. 

This check:

	//
    // Test whether the VLAN already exists
    //


    if ((pulled_vifp != NULL)
        && (pulled_vifp->is_vlan())
        && (pulled_vifp->vlan_id() == config_vif.vlan_id())) {
        return (XORP_OK);               // XXX: nothing changed
    }



Doesn't work.

If you create eth1.100 vif for example, commit, then go back and crate eth1.200, it tries to add eth1.100 again and bombs. 

Cannot create VLAN interface eth1.100 (parent = eth1 VLAN ID = 100): File exists


I wrote a quick ugly hack that puts the IP on the vlans and deletes them, but now this is a problem.

-- Joe



From greearb at candelatech.com  Tue Feb 15 11:29:59 2011
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 15 Feb 2011 11:29:59 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>,
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>,
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
	<4D59B4B7.7060603@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>
Message-ID: <4D5AD437.9000607@candelatech.com>

On 02/15/2011 11:32 AM, Joe Coco wrote:
> Hello,
>
> I found another problem.
>
> This check:
>
> 	//
>      // Test whether the VLAN already exists
>      //
>
>
>      if ((pulled_vifp != NULL)
>          &&  (pulled_vifp->is_vlan())
>          &&  (pulled_vifp->vlan_id() == config_vif.vlan_id())) {
>          return (XORP_OK);               // XXX: nothing changed
>      }
>
>
>
> Doesn't work.
>
> If you create eth1.100 vif for example, commit, then go back and crate eth1.200, it tries to add eth1.100 again and bombs.
>
> Cannot create VLAN interface eth1.100 (parent = eth1 VLAN ID = 100): File exists

I think I fixed one problem with the EEXIST already...are you using the latest xorp.ct git tree from github?
This is something you'd need to clone with git, not just download a canned snapshot.

Either way, you may still be correct about the test for VLAN existing....

In general, xorp.ct tries to keep two interface collections:

One is what we've discovered from the OS,
and the other is what is Configured by the user.
Generally, an interface needs to be in both trees
before it can be used by routing protocols, etc.

Thanks,
Ben

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


From jcoco at meccorp.mec.edu  Tue Feb 15 11:57:31 2011
From: jcoco at meccorp.mec.edu (Joe Coco)
Date: Tue, 15 Feb 2011 14:57:31 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D5AD437.9000607@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<C97AE59B.23592%dmoormann@meccorp.mec.edu>
	<65A6944974518C4B9C0E818727B559E9397F8431@mecexchange2007.meccorp.mec.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>,
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>,
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
	<4D59B4B7.7060603@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>
	<4D5AD437.9000607@candelatech.com>
Message-ID: <65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>

Hi Ben,

> I think I fixed one problem with the EEXIST already...are you using the latest xorp.ct git tree from github?
> This is something you'd need to clone with git, not just download a canned snapshot.

I'm actually merging your changes with mine now, and I do see you made a fix for that.  Doh! 

I wasn't really sure how far you got fixing up the vlan code based on your comments last night, so I continued in the direction I was going in until this afternoon. I'm merging your changes now, especially now that I know a bit more about the code and what you changed. 

So in GIT, where are we with your changes functionality wise? Did you get it to the point where you can add and delete dev.vid vlan's and it set the appropriate IP address?


Thanks!

-- Joe




From greearb at candelatech.com  Tue Feb 15 11:56:02 2011
From: greearb at candelatech.com (Ben Greear)
Date: Tue, 15 Feb 2011 11:56:02 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>,
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>,
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
	<4D59B4B7.7060603@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>
	<4D5AD437.9000607@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>
Message-ID: <4D5ADA52.8000108@candelatech.com>

On 02/15/2011 11:57 AM, Joe Coco wrote:
> Hi Ben,
>
>> I think I fixed one problem with the EEXIST already...are you using the latest xorp.ct git tree from github?
>> This is something you'd need to clone with git, not just download a canned snapshot.
>
> I'm actually merging your changes with mine now, and I do see you made a fix for that.  Doh!
>
> I wasn't really sure how far you got fixing up the vlan code based on your comments last night, so I continued in the direction I was going in until this afternoon. I'm merging your changes now, especially now that I know a bit more about the code and what you changed.
>
> So in GIT, where are we with your changes functionality wise? Did you get it to the point where you can add and delete dev.vid vlan's and it set the appropriate IP address?

Yes, but the interface will not be admin up, and all sorts of code will not
actually function properly.

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...

Thanks,
Ben

>
>
> Thanks!
>
> -- Joe
>


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


From jcoco at meccorp.mec.edu  Tue Feb 15 12:25:30 2011
From: jcoco at meccorp.mec.edu (Joe Coco)
Date: Tue, 15 Feb 2011 15:25:30 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D5ADA52.8000108@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>,
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>,
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
	<4D59B4B7.7060603@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>
	<4D5AD437.9000607@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>
	<4D5ADA52.8000108@candelatech.com>
Message-ID: <65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>

> 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	




From dmoormann at meccorp.mec.edu  Thu Feb 17 06:35:11 2011
From: dmoormann at meccorp.mec.edu (Dan Moormann)
Date: Thu, 17 Feb 2011 09:35:11 -0500
Subject: [Xorp-users] OSPF route export
Message-ID: <C9829A18.237B4%dmoormann@meccorp.mec.edu>

I've been working with xorp in the lab and I'm having trouble getting OSPF to export any routes.
I have it neighbor'd up and receiving routes without a problem, but it won't export any.
 I have set up a basic policy to export static and connected but neither works.  Am I missing something?

  policy-statement static {
        term export {
            from {
                protocol: "static"
            }
        }
        then {
            accept {
            }
        }
    }
    policy-statement connected {
        term export {
            from {
                protocol: "connected"
            }
        }
        then {
            accept {
            }
        }
    }

    router-id: 216.20.1.76
    area 0.0.0.0 {
        interface eth0 {
            vif eth0 {
                address 216.20.1.76 {
                }
            }
        }
    }
    export: "static,connected"





From greearb at candelatech.com  Thu Feb 17 09:55:33 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 17 Feb 2011 09:55:33 -0800
Subject: [Xorp-users] OSPF route export
In-Reply-To: <C9829A18.237B4%dmoormann@meccorp.mec.edu>
References: <C9829A18.237B4%dmoormann@meccorp.mec.edu>
Message-ID: <4D5D6115.7030505@candelatech.com>

On 02/17/2011 06:35 AM, Dan Moormann wrote:
> I've been working with xorp in the lab and I'm having trouble getting OSPF to export any routes.
> I have it neighbor'd up and receiving routes without a problem, but it won't export any.
>   I have set up a basic policy to export static and connected but neither works.  Am I missing something?
>
>    policy-statement static {
>          term export {
>              from {
>                  protocol: "static"
>              }
>          }
>          then {
>              accept {
>              }
>          }
>      }
>      policy-statement connected {
>          term export {
>              from {
>                  protocol: "connected"
>              }
>          }
>          then {
>              accept {
>              }
>          }
>      }
>
>      router-id: 216.20.1.76
>      area 0.0.0.0 {
>          interface eth0 {
>              vif eth0 {
>                  address 216.20.1.76 {
>                  }
>              }
>          }
>      }
>      export: "static,connected"

I checked my config-file generator and I put the policy statements
outside of the protocol block (except for the export: statement)

I'm not sure your way is wrong, but it might be worth a try...

Thanks,
Ben

>
>
>
>
> _______________________________________________
> 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


From dmoormann at meccorp.mec.edu  Thu Feb 17 10:25:50 2011
From: dmoormann at meccorp.mec.edu (Dan Moormann)
Date: Thu, 17 Feb 2011 13:25:50 -0500
Subject: [Xorp-users] OSPF route export
In-Reply-To: <4D5D6115.7030505@candelatech.com>
Message-ID: <C982D028.237F4%dmoormann@meccorp.mec.edu>

I don't' quite follow you.  The only place to "import or export" from what I'm seeing appear to be inside the protocol block.
As far as I can tell


On 2/17/11 12:55 PM, "Ben Greear" <greearb at candelatech.com> wrote:

On 02/17/2011 06:35 AM, Dan Moormann wrote:
> I've been working with xorp in the lab and I'm having trouble getting OSPF to export any routes.
> I have it neighbor'd up and receiving routes without a problem, but it won't export any.
>   I have set up a basic policy to export static and connected but neither works.  Am I missing something?
>
>    policy-statement static {
>          term export {
>              from {
>                  protocol: "static"
>              }
>          }
>          then {
>              accept {
>              }
>          }
>      }
>      policy-statement connected {
>          term export {
>              from {
>                  protocol: "connected"
>              }
>          }
>          then {
>              accept {
>              }
>          }
>      }
>
>      router-id: 216.20.1.76
>      area 0.0.0.0 {
>          interface eth0 {
>              vif eth0 {
>                  address 216.20.1.76 {
>                  }
>              }
>          }
>      }
>      export: "static,connected"

I checked my config-file generator and I put the policy statements
outside of the protocol block (except for the export: statement)

I'm not sure your way is wrong, but it might be worth a try...

Thanks,
Ben

>
>
>
>
> _______________________________________________
> 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




From greearb at candelatech.com  Thu Feb 17 10:19:48 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 17 Feb 2011 10:19:48 -0800
Subject: [Xorp-users] OSPF route export
In-Reply-To: <C982D028.237F4%dmoormann@meccorp.mec.edu>
References: <C982D028.237F4%dmoormann@meccorp.mec.edu>
Message-ID: <4D5D66C4.20708@candelatech.com>

On 02/17/2011 10:25 AM, Dan Moormann wrote:
> I don't' quite follow you.  The only place to "import or export" from what I'm seeing appear to be inside the protocol block.
> As far as I can tell

Maybe post your entire config file as an attachment?

Thanks,
Ben
>
>
> On 2/17/11 12:55 PM, "Ben Greear"<greearb at candelatech.com>  wrote:
>
> On 02/17/2011 06:35 AM, Dan Moormann wrote:
>> I've been working with xorp in the lab and I'm having trouble getting OSPF to export any routes.
>> I have it neighbor'd up and receiving routes without a problem, but it won't export any.
>>    I have set up a basic policy to export static and connected but neither works.  Am I missing something?
>>
>>     policy-statement static {
>>           term export {
>>               from {
>>                   protocol: "static"
>>               }
>>           }
>>           then {
>>               accept {
>>               }
>>           }
>>       }
>>       policy-statement connected {
>>           term export {
>>               from {
>>                   protocol: "connected"
>>               }
>>           }
>>           then {
>>               accept {
>>               }
>>           }
>>       }
>>
>>       router-id: 216.20.1.76
>>       area 0.0.0.0 {
>>           interface eth0 {
>>               vif eth0 {
>>                   address 216.20.1.76 {
>>                   }
>>               }
>>           }
>>       }
>>       export: "static,connected"
>
> I checked my config-file generator and I put the policy statements
> outside of the protocol block (except for the export: statement)
>
> I'm not sure your way is wrong, but it might be worth a try...
>
> Thanks,
> Ben
>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>


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


From dmoormann at meccorp.mec.edu  Thu Feb 17 11:02:38 2011
From: dmoormann at meccorp.mec.edu (Dan Moormann)
Date: Thu, 17 Feb 2011 14:02:38 -0500
Subject: [Xorp-users] OSPF route export
In-Reply-To: <4D5D66C4.20708@candelatech.com>
Message-ID: <C982D8C5.237FF%dmoormann@meccorp.mec.edu>

Here goes,


On 2/17/11 1:19 PM, "Ben Greear" <greearb at candelatech.com> wrote:

On 02/17/2011 10:25 AM, Dan Moormann wrote:
> I don't' quite follow you.  The only place to "import or export" from what I'm seeing appear to be inside the protocol block.
> As far as I can tell

Maybe post your entire config file as an attachment?

Thanks,
Ben
>
>
> On 2/17/11 12:55 PM, "Ben Greear"<greearb at candelatech.com>  wrote:
>
> On 02/17/2011 06:35 AM, Dan Moormann wrote:
>> I've been working with xorp in the lab and I'm having trouble getting OSPF to export any routes.
>> I have it neighbor'd up and receiving routes without a problem, but it won't export any.
>>    I have set up a basic policy to export static and connected but neither works.  Am I missing something?
>>
>>     policy-statement static {
>>           term export {
>>               from {
>>                   protocol: "static"
>>               }
>>           }
>>           then {
>>               accept {
>>               }
>>           }
>>       }
>>       policy-statement connected {
>>           term export {
>>               from {
>>                   protocol: "connected"
>>               }
>>           }
>>           then {
>>               accept {
>>               }
>>           }
>>       }
>>
>>       router-id: 216.20.1.76
>>       area 0.0.0.0 {
>>           interface eth0 {
>>               vif eth0 {
>>                   address 216.20.1.76 {
>>                   }
>>               }
>>           }
>>       }
>>       export: "static,connected"
>
> I checked my config-file generator and I put the policy statements
> outside of the protocol block (except for the export: statement)
>
> I'm not sure your way is wrong, but it might be worth a try...
>
> Thanks,
> Ben
>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.boot-ospftest
Type: video/x-ms-w
Size: 2706 bytes
Desc: config.boot-ospftest
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110217/fa4c82ea/attachment.bin 

From greearb at candelatech.com  Thu Feb 17 11:23:29 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 17 Feb 2011 11:23:29 -0800
Subject: [Xorp-users] OSPF route export
In-Reply-To: <C982D8C5.237FF%dmoormann@meccorp.mec.edu>
References: <C982D8C5.237FF%dmoormann@meccorp.mec.edu>
Message-ID: <4D5D75B1.6030909@candelatech.com>

On 02/17/2011 11:02 AM, Dan Moormann wrote:
> Here goes,
>
>
> On 2/17/11 1:19 PM, "Ben Greear"<greearb at candelatech.com>  wrote:
>
> On 02/17/2011 10:25 AM, Dan Moormann wrote:
>> I don't' quite follow you.  The only place to "import or export" from what I'm seeing appear to be inside the protocol block.
>> As far as I can tell
>
> Maybe post your entire config file as an attachment?

It looks like you are trying to use a VLAN as a vif.  I don't
think that can work properly, though I'm not sure if it is
the cause of the problems you currently see.

Can you try creating the VLAN outside of xorp and
using it as a normal interface in your config file?

Is xorp adding the static routes to the OS routing
tables?

Thanks,
Ben

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


From dmoormann at meccorp.mec.edu  Thu Feb 17 12:19:09 2011
From: dmoormann at meccorp.mec.edu (Dan Moormann)
Date: Thu, 17 Feb 2011 15:19:09 -0500
Subject: [Xorp-users] OSPF route export
In-Reply-To: <4D5D75B1.6030909@candelatech.com>
Message-ID: <C982EAB6.2380C%dmoormann@meccorp.mec.edu>

That works. So how does xorp know if an interface is admin'd up or down?



On 2/17/11 2:23 PM, "Ben Greear" <greearb at candelatech.com> wrote:

On 02/17/2011 11:02 AM, Dan Moormann wrote:
> Here goes,
>
>
> On 2/17/11 1:19 PM, "Ben Greear"<greearb at candelatech.com>  wrote:
>
> On 02/17/2011 10:25 AM, Dan Moormann wrote:
>> I don't' quite follow you.  The only place to "import or export" from what I'm seeing appear to be inside the protocol block.
>> As far as I can tell
>
> Maybe post your entire config file as an attachment?

It looks like you are trying to use a VLAN as a vif.  I don't
think that can work properly, though I'm not sure if it is
the cause of the problems you currently see.

Can you try creating the VLAN outside of xorp and
using it as a normal interface in your config file?

Is xorp adding the static routes to the OS routing
tables?

Thanks,
Ben

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




From greearb at candelatech.com  Thu Feb 17 13:30:19 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 17 Feb 2011 13:30:19 -0800
Subject: [Xorp-users] OSPF route export
In-Reply-To: <C982EAB6.2380C%dmoormann@meccorp.mec.edu>
References: <C982EAB6.2380C%dmoormann@meccorp.mec.edu>
Message-ID: <4D5D936B.3080302@candelatech.com>

On 02/17/2011 12:19 PM, Dan Moormann wrote:
> That works. So how does xorp know if an interface is admin'd up or down?

There are lots and lots of problems with trying to use
vifs of different name than the interface, as I previously
posted.

I also posted my suggestions for allowing auto-created
vlans (extend interface config options, not add more vifs).

Long term, seems to me we should just remove the vif idea entirely
and put the things under vif in the interface instead.

Thanks,
Ben


>
>
>
> On 2/17/11 2:23 PM, "Ben Greear"<greearb at candelatech.com>  wrote:
>
> On 02/17/2011 11:02 AM, Dan Moormann wrote:
>> Here goes,
>>
>>
>> On 2/17/11 1:19 PM, "Ben Greear"<greearb at candelatech.com>   wrote:
>>
>> On 02/17/2011 10:25 AM, Dan Moormann wrote:
>>> I don't' quite follow you.  The only place to "import or export" from what I'm seeing appear to be inside the protocol block.
>>> As far as I can tell
>>
>> Maybe post your entire config file as an attachment?
>
> It looks like you are trying to use a VLAN as a vif.  I don't
> think that can work properly, though I'm not sure if it is
> the cause of the problems you currently see.
>
> Can you try creating the VLAN outside of xorp and
> using it as a normal interface in your config file?
>
> Is xorp adding the static routes to the OS routing
> tables?
>
> Thanks,
> Ben
>
> --
> Ben Greear<greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>


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


From rps at maine.edu  Thu Feb 24 12:22:23 2011
From: rps at maine.edu (Ray Soucy)
Date: Thu, 24 Feb 2011 15:22:23 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
	<4D59B4B7.7060603@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>
	<4D5AD437.9000607@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>
	<4D5ADA52.8000108@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>
Message-ID: <AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>

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
>

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From jcoco at meccorp.mec.edu  Thu Feb 24 12:51:13 2011
From: jcoco at meccorp.mec.edu (Joe Coco)
Date: Thu, 24 Feb 2011 15:51:13 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
	<4D59B4B7.7060603@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>
	<4D5AD437.9000607@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>
	<4D5ADA52.8000108@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>
	<AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>
Message-ID: <65A6944974518C4B9C0E818727B559E9397F8C5A@mecexchange2007.meccorp.mec.edu>

Hi Ray,

> 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.

For my application there is really two options I'm considering. 

Continue the path I was on, and get the interfaces to show 'admin up' and work with OSPF,BGP, etc 

or

Add a 'wrapper' for vconfig such as:


vlan-database {

	vlan 100 port eth0
	vlan 200 port eth0
}

This would fork out to vconfig/ip to set up the interface. 

Essentially, fea then sees an eth0.100, and eth0.200 device pop up which can be configured. 

But that is ugly.


Perhaps I'll have more time next week to play with XORP again. All I want is one common configuration place. 
Hopefully what works for me can be contributed to the community for others to use.

I've got it to the point where the vlan VIF comes up and works, but routing processes such as OSPF don't
work properly. Ben said it's because the interface doesn't report as 'admin up', but I have not had the time
to go fishing to see how/where/when/why.


-- Joe





From nschmidt at mediamath.com  Thu Feb 24 13:30:27 2011
From: nschmidt at mediamath.com (Nicholas Schmidt)
Date: Thu, 24 Feb 2011 15:30:27 -0600
Subject: [Xorp-users] mfea4 issues
Message-ID: <C98C3823.15CBB%nschmidt@mediamath.com>

Greetings list,
I am attempting to run xorp for the first time to satisfy some multicast routing needs that is not currently supported by our hardware vendor. I have attempted to write the simplist possible configuration for my needs based on the guides provided by I receive an MFEA4 error when attempting to launch the application. Any help would be appreciated.

Log:

[ 2011/02/24 16:26:54  INFO xorp_rtrmgr:3981 RTRMGR +101 module_manager.cc execute ] Executing module: firewall (fea/xorp_fea)
[ 2011/02/24 16:26:58  INFO xorp_rtrmgr:3981 RTRMGR +101 module_manager.cc execute ] Executing module: fea (fea/xorp_fea)
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +101 module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea)
[ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] Interface added: Vif[eth0.33] pif_index: 4 vif_index: 0 addr: 74.121.138.180 subnet: 74.121.138.0/24 broadcast: 74.121.138.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500
[ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] Interface added: Vif[eth0.512] pif_index: 5 vif_index: 1 addr: 10.3.3.1 subnet: 10.3.3.0/24 broadcast: 10.3.3.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500
[ 2011/02/24 16:27:05  ERROR xorp_fea:3982 MFEA +709 mfea_mrouter.cc start_mrt ] setsockopt(MRT_INIT, 1) failed: Address already in use
[ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] MFEA started
[ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] Interface enabled Vif[eth0.33] pif_index: 4 vif_index: 0 addr: 74.121.138.180 subnet: 74.121.138.0/24 broadcast: 74.121.138.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
[ 2011/02/24 16:27:05  ERROR xorp_fea:3982 MFEA +1113 mfea_mrouter.cc add_multicast_vif ] setsockopt(MRT_ADD_VIF, vif eth0.33) failed: Address already in use
[ 2011/02/24 16:27:05  ERROR xorp_fea:3982 MFEA +1191 mfea_node.cc start_vif ] Cannot start vif eth0.33: cannot add the multicast vif to the kernel
[ 2011/02/24 16:27:05 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot start vif eth0.33: cannot add the multicast vif to the kernel
[ 2011/02/24 16:27:05  ERROR xorp_rtrmgr:3981 RTRMGR +691 master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed Cannot start vif eth0.33: cannot add the multicast vif to the kernel
[ 2011/02/24 16:27:05  ERROR xorp_rtrmgr:3981 RTRMGR +261 master_conf_tree.cc config_done ] Configuration failed: 102 Command failed Cannot start vif eth0.33: cannot add the multicast vif to the kernel
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +2233 task.cc run_task ] No more tasks to run
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc terminate ] Terminating module: fea
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc terminate ] Terminating module: firewall
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc terminate ] Terminating module: interfaces
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc terminate ] Terminating module: mfea4
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +199 module_manager.cc terminate ] Killing module: mfea4
[ 2011/02/24 16:27:05  ERROR xorp_rtrmgr:3981 RTRMGR +754 module_manager.cc done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 15.
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +287 module_manager.cc module_exited ] Module killed during shutdown: mfea4

Configuration:

interfaces {
    restore-original-config-on-shutdown: false
    interface eth0.33 {
    description: "data interface"
    disable: false
    /* default-system-config */
    vif eth0.33 {
        disable: false
        address 2.2.2.2 {
        prefix-length: 24
        broadcast: 2.2.2.255
        disable: false
        }
    }
    }
    interface eth0.512 {
    description: "data interface"
    disable: false
    /* default-system-config */
    vif eth0.512 {
        disable: false
        address 1.1.1.1 {
        prefix-length: 24
        broadcast: 1.1.1.255
        disable: false
        }
    }
    }
}

fea {
    unicast-forwarding4 {
        disable: false
    }
}
protocols {
    static {
    route 1.1.0.0/22 {
        next-hop: 10.3.3.2
        metric: 1
    }
    route 1.1.3.0/24 {
        next-hop: 74.121.138.1
        metric: 1
    }
   }
}

plumbing {
    mfea4 {
    disable: false
    interface eth0.33 {
        vif eth0.33 {
        disable: false
        }
    }
    interface eth0.512 {
        vif eth0.512 {
        disable: true
        }
    }
    interface register_vif {
        vif register_vif {
        /* Note: this vif should be always enabled */
        disable: false
        }
    }
    traceoptions {
        flag all {
        disable: false
        }
    }
    }
}


protocols {
    pimsm4 {
    disable: false
    interface eth0.33 {
        vif eth0.33 {
        disable: false
        /* enable-ip-router-alert-option-check: false */
        /* dr-priority: 1 */
        /* hello-period: 30 */
        /* hello-triggered-delay: 5 */
        }
    }
    interface eth0.512 {
        vif eth0.512 {
        disable: false
        /* enable-ip-router-alert-option-check: false */
        /* dr-priority: 1 */
        /* hello-period: 30 */
        /* hello-triggered-delay: 5 */
        }
    }
    interface register_vif {
        vif register_vif {
        /* Note: this vif should be always enabled */
        disable: false
        }
    }

    static-rps {
        rp 6.6.6.6 {
        group-prefix 224.0.0.0/4 {
            /* rp-priority: 192 */
            /* hash-mask-len: 30 */
        }
        }
    }

    switch-to-spt-threshold {
        /* approx. 1K bytes/s (10Kbps) threshold */
        disable: false
        interval: 100
        bytes: 102400
    }

    traceoptions {
        flag all {
        disable: false
        }
    }
   }
}
protocols {
    igmp {
    disable: false
    interface eth0.33 {
        vif eth0.33 {
        disable: false
        /* version: 2 */
        /* enable-ip-router-alert-option-check: false */
        /* query-interval: 125 */
        /* query-last-member-interval: 1 */
        /* query-response-interval: 10 */
        /* robust-count: 2 */
        }
    }
    interface eth0.512 {
        vif eth0.512 {
        disable: false
        /* version: 2 */
        /* enable-ip-router-alert-option-check: false */
        /* query-interval: 125 */
        /* query-last-member-interval: 1 */
        /* query-response-interval: 10 */
        /* robust-count: 2 */
        }
    }
    traceoptions {
        flag all {
        disable: false
        }
    }
    }
}

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110224/bbb32565/attachment-0001.html 

From rps at maine.edu  Thu Feb 24 14:39:44 2011
From: rps at maine.edu (Ray Soucy)
Date: Thu, 24 Feb 2011 17:39:44 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <1298580928.2186.5.camel@pierre-T500>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
	<4D59B4B7.7060603@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>
	<4D5AD437.9000607@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>
	<4D5ADA52.8000108@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>
	<AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>
	<1298580928.2186.5.camel@pierre-T500>
Message-ID: <AANLkTi=bvtGzts5TUui9o35ggiwkZtb9x+59d6pLsEok@mail.gmail.com>

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.

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
>> >
>>
>
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/
-------------- next part --------------
XORP configuration guide for XORP 1.6 (Suppliment to the XORP 1.6 User Manual)




Interface Configuration:

For XORP to work, you need to define which interfaces the XORP engine will make use of.  Interface configuration can be performed manually, or XORP can import the existing interface configuration from the system using the "default-system-config" statement.

For example, to import the configuration for the "lo" loopback interface:

    interface lo {
        description: "Loopback"
        disable: false
        discard: false
        unreachable: false
        management: false
        default-system-config {
        }
    }

And here is an example of manual interface configuration:

    interface eth0 {
        description: "LAN"
        disable: false
        discard: false
        unreachable: false
        management: false
        vif eth0 {
            disable: false
            address 192.168.0.1 {
                prefix-length: 24
                disable: false
            }
        }
    }

VLAN configuration is broken in XORP.  VLAN interfaces must be manually created (using vconfig) on the host system and defined as physical interfaces in XORP rather than sub-interface VIF's.  You can not use "default-system-config" on the parent or any sub-interface that makes use of VLAN's.

    interface eth1 {
        description: "802.1Q Trunk Port (Native)"
        disable: false
        discard: false
        unreachable: false
        management: false
        vif eth0 {
            disable: false
        }
    }
    interface "eth1.2" {
        description: "VLAN 2"
        disable: false
        discard: false
        unreachable: false
        management: false
        vif "eth1.2" {
            disable: false
            address 192.168.2.1 {
                prefix-length: 24
                disable: false
            }
        }
    }
    interface "eth1.3" {
        description: "VLAN 3"
        disable: false
        discard: false
        unreachable: false
        management: false
        vif "eth1.3" {
            disable: false
            address 192.168.3.1 {
                prefix-length: 24
                disable: false
            }
        }
    }




Basic Configuration:

Below is an example configuration file.  This configuration defines 2 intefaces and the loopback interface (allowing loopback aliases to be advertised routes).  It also provides a sample policy to restrict the routes advertised so that the Loopback network, RFC 1918 private networks, and default route are not advertised.

/*XORP Configuration File, v1.0*/
protocols {
    fib2mrib {
        disable: true
    }
}
policy {
    policy-statement "Route_Export" {
        term 10 {
            from {
                protocol: "connected"
                network4-list: "Default_Route"
            }
            then {
                reject {
                }
            }
        }
        term 20 {
            from {
                protocol: "connected"
                network4-list: "No_Advertise"
            }
            then {
                reject {
                }
            }
        }
        term 30 {
            from {
                protocol: "connected"
		prefix-length4 < 32..32
            }
            then {
                accept {
                }
            }
        }
        then {
            reject {
            }
        }
    }
    network4-list "No_Advertise" {
        network 127.0.0.0/8 {
            modifier: "orlonger"
        }
        network 10.0.0.0/8 {
            modifier: "orlonger"
        }
        network 172.16.0.0/12 {
            modifier: "orlonger"
        }
        network 192.168.0.0/16 {
            modifier: "orlonger"
        }
    }
    network4-list "Default_Route" {
        network 0.0.0.0/0
    }
}
fea {
    unicast-forwarding4 {
        disable: false
        forwarding-entries {
            retain-on-startup: true
            retain-on-shutdown: true
        }
    }
}
interfaces {
    restore-original-config-on-shutdown: true
    interface lo {
        description: "Loopback"
        disable: false
        discard: false
        unreachable: false
        management: false
        default-system-config {
        }
    }
    interface eth0 {
        description: "WAN"
        disable: false
        discard: false
        unreachable: false
        management: false
        default-system-config {
        }
    }
    interface eth1 {
        description: "LAN"
        disable: false
        discard: false
        unreachable: false
        management: false
        default-system-config {
        }
    }
}
rtrmgr {
    config-directory: "/home/xorp/"
    load-file-command: "fetch"
    load-file-command-args: "-o"
    load-ftp-command: "fetch"
    load-ftp-command-args: "-o"
    load-http-command: "fetch"
    load-http-command-args: "-o"
    load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    load-tftp-command-args: ""
    save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-file-command-args: ""
    save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-ftp-command-args: ""
    save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-http-command-args: ""
    save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-tftp-command-args: ""
}



Multicast Configuration:

For IP multicast routing, you need to enable the fib2mrib protocol, create a plumbing configuration block to define the multicast fea (mfea), and enable your desired protocol(s).  In this example we will use PIM-SM, and IGMP, which is they most common configuration.

Note that the "register_vif" interface is created by the pimsm4 process.  You must correctly define pimsm4 for the interface to be available for mfea4 configuration.  Also note that manual address configuration is recommended for interfaces.  The "register_vif" interface must be defined last.

/*XORP Configuration File, v1.0*/
protocols {
    fib2mrib {
        disable: false
    }
    igmp {
        disable: true
        interface eth1 {
            vif eth1 {
                disable: true
                version: 2
                enable-ip-router-alert-option-check: false
                query-interval: 125
                query-last-member-interval: 1
                query-response-interval: 10
                robust-count: 2
            }
        }
    }
    pimsm4 {
        disable: true
        interface eth0 {
            vif eth0 {
                disable: true
                dr-priority: 1
                hello-period: 30
                hello-triggered-delay: 5
            }
        }
        interface "register_vif" {
            vif "register_vif" {
                disable: false
                dr-priority: 1
                hello-period: 30
                hello-triggered-delay: 5
            }
        }
        static-rps {
            rp 203.0.113.1 {
                group-prefix 224.0.0.0/4 {
                    rp-priority: 192
                    hash-mask-len: 30
                }
            }
        }
        bootstrap {
          disable: false
        }
    }
}
fea {
    unicast-forwarding4 {
        disable: false
        forwarding-entries {
            retain-on-startup: true
            retain-on-shutdown: true
        }
    }
}
interfaces {
    restore-original-config-on-shutdown: true
    interface lo {
        description: "Loopback"
        disable: false
        discard: false
        unreachable: false
        management: false
        default-system-config {
        }
    }
    interface eth0 {
        description: "WAN"
        disable: false
        discard: false
        unreachable: false
        management: false
        vif eth0 {
            disable: false
            address 198.51.100.6 {
                prefix-length: 30
                disable: false
            }
        }
    }
    interface eth1 {
        description: "LAN"
        disable: false
        discard: false
        unreachable: false
        management: false
        vif eth1 {
            disable: false
            address 203.0.113.1 {
                prefix-length: 24
                disable: false
            }
        }
    }
}
plumbing {
    mfea4 {
        disable: false
        interface eth0 {
            vif eth0 {
                disable: false
            }
        }
        interface eth1 {
            vif eth1 {
                disable: false
            }
        }
        interface "register_vif" {
            vif "register_vif" {
                disable: false
            }
        }
    }
}
rtrmgr {
    config-directory: "/home/xorp/"
    load-file-command: "fetch"
    load-file-command-args: "-o"
    load-ftp-command: "fetch"
    load-ftp-command-args: "-o"
    load-http-command: "fetch"
    load-http-command-args: "-o"
    load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    load-tftp-command-args: ""
    save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-file-command-args: ""
    save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-ftp-command-args: ""
    save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-http-command-args: ""
    save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-tftp-command-args: ""
}




Routing Configuration (Static):

protocols {
   static {
        disable: false
        route 0.0.0.0/0 {
            next-hop: 198.51.100.5
            metric: 1
        }
        route 192.0.2.0/24 {
            next-hop: 203.0.113.2
            metric: 1
        }
    }
}




Routing Configuration (RIP):

protocols {
    rip {
        interface eth0 {
            vif eth0 {
                address 198.51.100.6 {
                    metric: 1
                    horizon: "split-horizon-poison-reverse"
                    disable: false
                    passive: false
                    accept-non-rip-requests: false
                    accept-default-route: true
                    advertise-default-route: false
                    route-timeout: 180
                    deletion-delay: 120
                    triggered-delay: 3
                    triggered-jitter: 66
                    update-interval: 30
                    update-jitter: 16
                    request-interval: 30
                    interpacket-delay: 50
                }
            }
        }
    export: "Route_Export"
    }
}




Routing Configuration (OSPF):

protocols {
    ospf4 {
        router-id: 198.51.100.6
        rfc1583-compatibility: false
        ip-router-alert: false
        area 0.0.0.10 {
            area-type: "normal"
            default-lsa {
                disable: false
                metric: 0
            }
            interface eth0 {
                link-type: "broadcast"
                vif eth0 {
                    address 198.51.100.6 {
                        priority: 255
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        retransmit-interval: 5
                        transit-delay: 1
                        authentication {
                            simple-password: "password"
                        }
                        disable: false
                    }
                }
            }
        }
        export: "Route_Export"
    }
}




Full example (PIM-SM, OSPF):

/*XORP Configuration File, v1.0*/
protocols {
    fib2mrib {
        disable: false
    }
    igmp {
        disable: true
        interface eth1 {
            vif eth1 {
                disable: true
                version: 2
                enable-ip-router-alert-option-check: false
                query-interval: 125
                query-last-member-interval: 1
                query-response-interval: 10
                robust-count: 2
            }
        }
    }
    pimsm4 {
        disable: true
        interface eth0 {
            vif eth0 {
                disable: true
                dr-priority: 1
                hello-period: 30
                hello-triggered-delay: 5
            }
        }
        interface "register_vif" {
            vif "register_vif" {
                disable: false
                dr-priority: 1
                hello-period: 30
                hello-triggered-delay: 5
            }
        }
        static-rps {
            rp 203.0.113.1 {
                group-prefix 224.0.0.0/4 {
                    rp-priority: 192
                    hash-mask-len: 30
                }
            }
        }
        bootstrap {
            disable: false
        }
    }
    ospf4 {
        router-id: 198.51.100.6
        rfc1583-compatibility: false
        ip-router-alert: false
        area 0.0.0.10 {
            area-type: "normal"
            default-lsa {
                disable: false
                metric: 0
            }
            interface eth0 {
                link-type: "broadcast"
                vif eth0 {
                    address 198.51.100.6 {
                        priority: 255
                        hello-interval: 10
                        router-dead-interval: 40
                        interface-cost: 1
                        retransmit-interval: 5
                        transit-delay: 1
                        authentication {
                            simple-password: "password"
                        }
                        disable: false
                    }
                }
            }
        }
        export: "Route_Export"
    }
    static {
        disable: false
        route 0.0.0.0/0 {
            next-hop: 198.51.100.5
            metric: 1
        }
        route 192.0.2.0/24 {
            next-hop: 203.0.113.2
            metric: 1
        }
    }
}
policy {
    policy-statement "Route_Export" {
        term 10 {
            from {
                protocol: "connected"
                network4-list: "Default_Route"
            }
            then {
                reject {
                }
            }
        }
        term 20 {
            from {
                protocol: "connected"
                network4-list: "No_Advertise"
            }
            then {
                reject {
                }
            }
        }
        term 30 {
            from {
                protocol: "connected"
		prefix-length4 < 32..32
            }
            then {
                accept {
                }
            }
        }
        then {
            reject {
            }
        }
    }
    network4-list "No_Advertise" {
        network 127.0.0.0/8 {
            modifier: "orlonger"
        }
        network 10.0.0.0/8 {
            modifier: "orlonger"
        }
        network 172.16.0.0/12 {
            modifier: "orlonger"
        }
        network 192.168.0.0/16 {
            modifier: "orlonger"
        }
    }
    network4-list "Default_Route" {
        network 0.0.0.0/0
    }
}
fea {
    unicast-forwarding4 {
        disable: false
        forwarding-entries {
            retain-on-startup: true
            retain-on-shutdown: true
        }
    }
}
interfaces {
    restore-original-config-on-shutdown: true
    interface lo {
        description: "Loopback"
        disable: false
        discard: false
        unreachable: false
        management: false
        default-system-config {
        }
    }
    interface eth0 {
        description: "WAN"
        disable: false
        discard: false
        unreachable: false
        management: false
        vif eth0 {
            disable: false
            address 198.51.100.6 {
                prefix-length: 30
                disable: false
            }
        }
    }
    interface eth1 {
        description: "LAN"
        disable: false
        discard: false
        unreachable: false
        management: false
        vif eth1 {
            disable: false
            address 203.0.113.1 {
                prefix-length: 24
                disable: false
            }
        }
    }
}
plumbing {
    mfea4 {
        disable: false
        interface eth0 {
            vif eth0 {
                disable: false
            }
        }
        interface eth1 {
            vif eth1 {
                disable: false
            }
        }
        interface "register_vif" {
            vif "register_vif" {
                disable: false
            }
        }
    }
}
rtrmgr {
    config-directory: "/home/xorp/"
    load-file-command: "fetch"
    load-file-command-args: "-o"
    load-ftp-command: "fetch"
    load-ftp-command-args: "-o"
    load-http-command: "fetch"
    load-http-command-args: "-o"
    load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    load-tftp-command-args: ""
    save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-file-command-args: ""
    save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-ftp-command-args: ""
    save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-http-command-args: ""
    save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-tftp-command-args: ""
}

From greearb at candelatech.com  Thu Feb 24 16:23:15 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 24 Feb 2011 16:23:15 -0800
Subject: [Xorp-users] mfea4 issues
In-Reply-To: <C98C3823.15CBB%nschmidt@mediamath.com>
References: <C98C3823.15CBB%nschmidt@mediamath.com>
Message-ID: <4D66F673.3050306@candelatech.com>

On 02/24/2011 01:30 PM, Nicholas Schmidt wrote:
> Greetings list,
> I am attempting to run xorp for the first time to satisfy some multicast routing needs that is not currently supported by our hardware vendor. I have attempted
> to write the simplist possible configuration for my needs based on the guides provided by I receive an MFEA4 error when attempting to launch the application.
> Any help would be appreciated.

Are you running any other routing daemons, or maybe some xorp processes
running in the background?

What xorp version?

What kernel version?

Thanks,
Ben

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


From greearb at candelatech.com  Thu Feb 24 16:51:40 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 24 Feb 2011 16:51:40 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <AANLkTi=bvtGzts5TUui9o35ggiwkZtb9x+59d6pLsEok@mail.gmail.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>	<4D594C19.4010504@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>	<4D598F5B.1000405@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>	<4D59AA1E.7000608@candelatech.com>	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>	<4D59AF8A.4040502@candelatech.com>	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>	<4D59B4B7.7060603@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>	<4D5AD437.9000607@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>	<4D5ADA52.8000108@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>	<AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>	<1298580928.2186.5.camel@pierre-T500>
	<AANLkTi=bvtGzts5TUui9o35ggiwkZtb9x+59d6pLsEok@mail.gmail.! com>
Message-ID: <4D66FD1C.8030602@candelatech.com>

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


From peirce at maine.edu  Thu Feb 24 17:06:26 2011
From: peirce at maine.edu (Garry Peirce)
Date: Thu, 24 Feb 2011 20:06:26 -0500
Subject: [Xorp-users] mfea4 issues
In-Reply-To: <4D66F673.3050306@candelatech.com>
References: <C98C3823.15CBB%nschmidt@mediamath.com>
	<4D66F673.3050306@candelatech.com>
Message-ID: <c8d0ffd7-c191-4fd0-b36b-f11356da4055@email.android.com>

Nicholas,
It would help if you could post your config and the error you are seeing.
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Ben Greear <greearb at candelatech.com> wrote:

On 02/24/2011 01:30 PM, Nicholas Schmidt wrote: > Greetings list, > I am attempting to run xorp for the first time to satisfy some multicast routing needs that is not currently supported by our hardware vendor. I have attempted > to write the simplist possible configuration for my needs based on the guides provided by I receive an MFEA4 error when attempting to launch the application. > Any help would be appreciated. Are you running any other routing daemons, or maybe some xorp processes running in the background? What xorp version? What kernel version? Thanks, Ben -- Ben Greear <greearb at candelatech.com> Candela Technologies Inc http://www.candelatech.com_____________________________________________
Xorp-users mailing list Xorp-users at xorp.org http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110224/f06d30b4/attachment.html 

From rps at maine.edu  Thu Feb 24 19:10:40 2011
From: rps at maine.edu (Ray Soucy)
Date: Thu, 24 Feb 2011 22:10:40 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D66FD1C.8030602@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
	<4D59B4B7.7060603@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>
	<4D5AD437.9000607@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>
	<4D5ADA52.8000108@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>
	<AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>
	<1298580928.2186.5.camel@pierre-T500>
	<AANLkTi=bvtGzts5TUui9o35ggiwkZtb9x+59d6pLsEok@mail.gmail.com>
	<4D66FD1C.8030602@candelatech.com>
Message-ID: <AANLkTi=waB5eC=8yGPro5kvbD8D_DtsYH_xqgCVZq+_U@mail.gmail.com>

Do we know who maintains the official xorp.org site?  I would be
willing to spend some time updating it.  Ultimately it would be nice
to see CT changes merged back in and see XORP active again.

On Thu, Feb 24, 2011 at 7:51 PM, Ben Greear <greearb at candelatech.com> wrote:
> 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
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From greearb at candelatech.com  Thu Feb 24 21:31:32 2011
From: greearb at candelatech.com (Ben Greear)
Date: Thu, 24 Feb 2011 21:31:32 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <AANLkTi=waB5eC=8yGPro5kvbD8D_DtsYH_xqgCVZq+_U@mail.gmail.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>	<4D598F5B.1000405@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>	<4D59AA1E.7000608@candelatech.com>	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>	<4D59AF8A.4040502@candelatech.com>	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>	<4D59B4B7.7060603@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>	<4D5AD437.9000607@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>	<4D5ADA52.8000108@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>	<AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>	<1298580928.2186.5.camel@pierre-T500>	<AANLkTi=bvtGzts5TUui9o35ggiwkZtb9x+59d6pLsEok@mail.gmail.com>	<4D66FD1C.8030602@candelatech.com>
	<AANLkTi=waB5eC=8yGPro5kvbD8D_DtsYH_xqgCVZq+_U@mail.gmail.com>
Message-ID: <4D673EB4.9080507@candelatech.com>

On 02/24/2011 07:10 PM, Ray Soucy wrote:
> Do we know who maintains the official xorp.org site?  I would be
> willing to spend some time updating it.  Ultimately it would be nice
> to see CT changes merged back in and see XORP active again.

They do not seem to be active (for several years now).  If you want, you are welcome to
send patches to the xorp.ct web page (html is in the git tree
as well).

I surely wouldn't mind if xorp.org comes back to life, but at this point,
I don't think it's likely.  Thankfully, XORP is GPL, so I can keep the
code alive via xorp.ct, and I'm happy to consider patches from anyone
who is interested.

Thanks,
Ben

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


From nschmidt at mediamath.com  Fri Feb 25 08:32:26 2011
From: nschmidt at mediamath.com (Nicholas Schmidt)
Date: Fri, 25 Feb 2011 10:32:26 -0600
Subject: [Xorp-users] mfea4 issues
In-Reply-To: <4D66F673.3050306@candelatech.com>
Message-ID: <C98D43CA.15EEA%nschmidt@mediamath.com>

This is a clean installation of Debian with no routing processes in the background running Kernel 2.6.26-2-amd64 and xorp version 1.6

-Nick


On 2/24/11 7:23 PM, "Ben Greear" <greearb at candelatech.com> wrote:

On 02/24/2011 01:30 PM, Nicholas Schmidt wrote:
> Greetings list,
> I am attempting to run xorp for the first time to satisfy some multicast routing needs that is not currently supported by our hardware vendor. I have attempted
> to write the simplist possible configuration for my needs based on the guides provided by I receive an MFEA4 error when attempting to launch the application.
> Any help would be appreciated.

Are you running any other routing daemons, or maybe some xorp processes
running in the background?

What xorp version?

What kernel version?

Thanks,
Ben

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110225/44d22764/attachment.html 

From greearb at candelatech.com  Fri Feb 25 08:35:57 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 25 Feb 2011 08:35:57 -0800
Subject: [Xorp-users] mfea4 issues
In-Reply-To: <C98D43CA.15EEA%nschmidt@mediamath.com>
References: <C98D43CA.15EEA%nschmidt@mediamath.com>
Message-ID: <4D67DA6D.8000703@candelatech.com>

On 02/25/2011 08:32 AM, Nicholas Schmidt wrote:
> This is a clean installation of Debian with no routing processes in the background running Kernel 2.6.26-2-amd64 and xorp version 1.6
>
> -Nick

Please try xorp.ct if you get a chance.  It can work on a kernel of that
vintage, assuming it's compiled for mcast routing support, etc.

Thanks,
Ben

>
>
> On 2/24/11 7:23 PM, "Ben Greear" <greearb at candelatech.com> wrote:
>
>     On 02/24/2011 01:30 PM, Nicholas Schmidt wrote:
>     >  Greetings list,
>     >  I am attempting to run xorp for the first time to satisfy some multicast routing needs that is not currently supported by our hardware vendor. I have
>     attempted
>     >  to write the simplist possible configuration for my needs based on the guides provided by I receive an MFEA4 error when attempting to launch the application.
>     >  Any help would be appreciated.
>
>     Are you running any other routing daemons, or maybe some xorp processes
>     running in the background?
>
>     What xorp version?
>
>     What kernel version?
>
>     Thanks,
>     Ben
>
>     --
>     Ben Greear <greearb at candelatech.com>
>     Candela Technologies Inc http://www.candelatech.com
>


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


From rps at maine.edu  Fri Feb 25 08:41:22 2011
From: rps at maine.edu (Ray Soucy)
Date: Fri, 25 Feb 2011 11:41:22 -0500
Subject: [Xorp-users] mfea4 issues
In-Reply-To: <C98D43CA.15EEA%nschmidt@mediamath.com>
References: <4D66F673.3050306@candelatech.com>
	<C98D43CA.15EEA%nschmidt@mediamath.com>
Message-ID: <AANLkTi=uYwfN5FhC5ddyHqXgU01MZNo-6_d34xic6N5M@mail.gmail.com>

Hi Nicholas,

We have a pretty large XORP deployment for multicast.  In our
experience 90% of problems people run into are configuration issues.

Can you provide us with your XORP configuration?  Also be sure to
check that you don't have iptables blocking the traffic.

On Fri, Feb 25, 2011 at 11:32 AM, Nicholas Schmidt
<nschmidt at mediamath.com> wrote:
> This is a clean installation of Debian with no routing processes in the
> background running Kernel 2.6.26-2-amd64 and xorp version 1.6
>
> -Nick
>
>
> On 2/24/11 7:23 PM, "Ben Greear" <greearb at candelatech.com> wrote:
>
> On 02/24/2011 01:30 PM, Nicholas Schmidt wrote:
>> Greetings list,
>> I am attempting to run xorp for the first time to satisfy some multicast
>> routing needs that is not currently supported by our hardware vendor. I have
>> attempted
>> to write the simplist possible configuration for my needs based on the
>> guides provided by I receive an MFEA4 error when attempting to launch the
>> application.
>> Any help would be appreciated.
>
> Are you running any other routing daemons, or maybe some xorp processes
> running in the background?
>
> What xorp version?
>
> What kernel version?
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From nschmidt at mediamath.com  Fri Feb 25 08:46:03 2011
From: nschmidt at mediamath.com (Nicholas Schmidt)
Date: Fri, 25 Feb 2011 10:46:03 -0600
Subject: [Xorp-users] mfea4 issues
In-Reply-To: <AANLkTi=uYwfN5FhC5ddyHqXgU01MZNo-6_d34xic6N5M@mail.gmail.com>
Message-ID: <C98D46FB.15F0E%nschmidt@mediamath.com>

I have provided the configuration and error in my original email. Here it is again for those who have missed it. I have read through and configured per the Getting Started documentation.

-Nick

Log:

[ 2011/02/24 16:26:54  INFO xorp_rtrmgr:3981 RTRMGR +101 module_manager.cc execute ] Executing module: firewall (fea/xorp_fea)
[ 2011/02/24 16:26:58  INFO xorp_rtrmgr:3981 RTRMGR +101 module_manager.cc execute ] Executing module: fea (fea/xorp_fea)
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +101 module_manager.cc execute ] Executing module: mfea4 (fea/xorp_fea)
[ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] Interface added: Vif[eth0.33] pif_index: 4 vif_index: 0 addr: 74.121.138.180 subnet: 74.121.138.0/24 broadcast: 74.121.138.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500
[ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] Interface added: Vif[eth0.512] pif_index: 5 vif_index: 1 addr: 10.3.3.1 subnet: 10.3.3.0/24 broadcast: 10.3.3.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500
[ 2011/02/24 16:27:05  ERROR xorp_fea:3982 MFEA +709 mfea_mrouter.cc start_mrt ] setsockopt(MRT_INIT, 1) failed: Address already in use
[ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] MFEA started
[ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] Interface enabled Vif[eth0.33] pif_index: 4 vif_index: 0 addr: 74.121.138.180 subnet: 74.121.138.0/24 broadcast: 74.121.138.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
[ 2011/02/24 16:27:05  ERROR xorp_fea:3982 MFEA +1113 mfea_mrouter.cc add_multicast_vif ] setsockopt(MRT_ADD_VIF, vif eth0.33) failed: Address already in use
[ 2011/02/24 16:27:05  ERROR xorp_fea:3982 MFEA +1191 mfea_node.cc start_vif ] Cannot start vif eth0.33: cannot add the multicast vif to the kernel
[ 2011/02/24 16:27:05 WARNING xorp_fea XrlMfeaTarget ] Handling method for mfea/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot start vif eth0.33: cannot add the multicast vif to the kernel
[ 2011/02/24 16:27:05  ERROR xorp_rtrmgr:3981 RTRMGR +691 master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed Cannot start vif eth0.33: cannot add the multicast vif to the kernel
[ 2011/02/24 16:27:05  ERROR xorp_rtrmgr:3981 RTRMGR +261 master_conf_tree.cc config_done ] Configuration failed: 102 Command failed Cannot start vif eth0.33: cannot add the multicast vif to the kernel
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +2233 task.cc run_task ] No more tasks to run
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc terminate ] Terminating module: fea
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc terminate ] Terminating module: firewall
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc terminate ] Terminating module: interfaces
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc terminate ] Terminating module: mfea4
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +199 module_manager.cc terminate ] Killing module: mfea4
[ 2011/02/24 16:27:05  ERROR xorp_rtrmgr:3981 RTRMGR +754 module_manager.cc done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 15.
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +287 module_manager.cc module_exited ] Module killed during shutdown: mfea4

Configuration:

interfaces {
    restore-original-config-on-shutdown: false
    interface eth0.33 {
    description: "data interface"
    disable: false
    /* default-system-config */
    vif eth0.33 {
        disable: false
        address 2.2.2.2 {
        prefix-length: 24
        broadcast: 2.2.2.255
        disable: false
        }
    }
    }
    interface eth0.512 {
    description: "data interface"
    disable: false
    /* default-system-config */
    vif eth0.512 {
        disable: false
        address 1.1.1.1 {
        prefix-length: 24
        broadcast: 1.1.1.255
        disable: false
        }
    }
    }
}

fea {
    unicast-forwarding4 {
        disable: false
    }
}
protocols {
    static {
    route 1.1.0.0/22 {
        next-hop: 10.3.3.2
        metric: 1
    }
    route 1.1.3.0/24 {
        next-hop: 74.121.138.1
        metric: 1
    }
   }
}

plumbing {
    mfea4 {
    disable: false
    interface eth0.33 {
        vif eth0.33 {
        disable: false
        }
    }
    interface eth0.512 {
        vif eth0.512 {
        disable: true
        }
    }
    interface register_vif {
        vif register_vif {
        /* Note: this vif should be always enabled */
        disable: false
        }
    }
    traceoptions {
        flag all {
        disable: false
        }
    }
    }
}


protocols {
    pimsm4 {
    disable: false
    interface eth0.33 {
        vif eth0.33 {
        disable: false
        /* enable-ip-router-alert-option-check: false */
        /* dr-priority: 1 */
        /* hello-period: 30 */
        /* hello-triggered-delay: 5 */
        }
    }
    interface eth0.512 {
        vif eth0.512 {
        disable: false
        /* enable-ip-router-alert-option-check: false */
        /* dr-priority: 1 */
        /* hello-period: 30 */
        /* hello-triggered-delay: 5 */
        }
    }
    interface register_vif {
        vif register_vif {
        /* Note: this vif should be always enabled */
        disable: false
        }
    }

    static-rps {
        rp 6.6.6.6 {
        group-prefix 224.0.0.0/4 {
            /* rp-priority: 192 */
            /* hash-mask-len: 30 */
        }
        }
    }

    switch-to-spt-threshold {
        /* approx. 1K bytes/s (10Kbps) threshold */
        disable: false
        interval: 100
        bytes: 102400
    }

    traceoptions {
        flag all {
        disable: false
        }
    }
   }
}
protocols {
    igmp {
    disable: false
    interface eth0.33 {
        vif eth0.33 {
        disable: false
        /* version: 2 */
        /* enable-ip-router-alert-option-check: false */
        /* query-interval: 125 */
        /* query-last-member-interval: 1 */
        /* query-response-interval: 10 */
        /* robust-count: 2 */
        }
    }
    interface eth0.512 {
        vif eth0.512 {
        disable: false
        /* version: 2 */
        /* enable-ip-router-alert-option-check: false */
        /* query-interval: 125 */
        /* query-last-member-interval: 1 */
        /* query-response-interval: 10 */
        /* robust-count: 2 */
        }
    }
    traceoptions {
        flag all {
        disable: false
        }
    }
    }
}





On 2/25/11 11:41 AM, "Ray Soucy" <rps at maine.edu> wrote:

Hi Nicholas,

We have a pretty large XORP deployment for multicast.  In our
experience 90% of problems people run into are configuration issues.

Can you provide us with your XORP configuration?  Also be sure to
check that you don't have iptables blocking the traffic.

On Fri, Feb 25, 2011 at 11:32 AM, Nicholas Schmidt
<nschmidt at mediamath.com> wrote:
> This is a clean installation of Debian with no routing processes in the
> background running Kernel 2.6.26-2-amd64 and xorp version 1.6
>
> -Nick
>
>
> On 2/24/11 7:23 PM, "Ben Greear" <greearb at candelatech.com> wrote:
>
> On 02/24/2011 01:30 PM, Nicholas Schmidt wrote:
>> Greetings list,
>> I am attempting to run xorp for the first time to satisfy some multicast
>> routing needs that is not currently supported by our hardware vendor. I have
>> attempted
>> to write the simplist possible configuration for my needs based on the
>> guides provided by I receive an MFEA4 error when attempting to launch the
>> application.
>> Any help would be appreciated.
>
> Are you running any other routing daemons, or maybe some xorp processes
> running in the background?
>
> What xorp version?
>
> What kernel version?
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
>



--
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110225/1bb8753e/attachment-0001.html 

From rps at maine.edu  Fri Feb 25 10:22:06 2011
From: rps at maine.edu (Ray Soucy)
Date: Fri, 25 Feb 2011 13:22:06 -0500
Subject: [Xorp-users] mfea4 issues
In-Reply-To: <C98D46FB.15F0E%nschmidt@mediamath.com>
References: <AANLkTi=uYwfN5FhC5ddyHqXgU01MZNo-6_d34xic6N5M@mail.gmail.com>
	<C98D46FB.15F0E%nschmidt@mediamath.com>
Message-ID: <AANLkTimvekAqnhHjGem5209AV1fco-rgT1MUvs6jbwQT@mail.gmail.com>

"[ 2011/02/24 16:27:05  ERROR xorp_fea:3982 MFEA +1191 mfea_node.cc
start_vif ] Cannot start vif eth0.33: cannot add the multicast vif to
the kernel"

Your config looks pretty choppy.  XORP is a little sensitive to
ordering of configuration.  It looks like it's not configuring eth0.33
correctly, also not sure how well it will handle multiple protocol
blocks.

You also forgot to enable fib2mrib.

Be sure that the vlan interfaces have been created and exist before
you start XORP, then try this config:

----8<----
/*XORP Configuration File, v1.0*/
protocols {
    fib2mrib {
        disable: false
    }
    igmp {
        disable: false
        interface "eth0.33" {
            vif "eth0.33" {
                disable: false
                version: 2
                enable-ip-router-alert-option-check: false
                query-interval: 125
                query-last-member-interval: 1
                query-response-interval: 10
                robust-count: 2
            }
        }
        interface "eth0.512" {
            vif "eth0.512" {
                disable: false
                version: 2
                enable-ip-router-alert-option-check: false
                query-interval: 125
                query-last-member-interval: 1
                query-response-interval: 10
                robust-count: 2
            }
        }
    }
    pimsm4 {
        disable: false
        interface "eth0.33" {
            vif "eth0.33" {
                disable: false
                dr-priority: 1
                hello-period: 30
                hello-triggered-delay: 5
            }
        }
        interface "eth0.512" {
            vif "eth0.512" {
                disable: false
                dr-priority: 1
                hello-period: 30
                hello-triggered-delay: 5
            }
        }
        interface "register_vif" {
            vif "register_vif" {
                disable: false
                dr-priority: 1
                hello-period: 30
                hello-triggered-delay: 5
            }
        }
        static-rps {
            rp 6.6.6.6 {
                group-prefix 224.0.0.0/4 {
                    rp-priority: 192
                    hash-mask-len: 30
                }
            }
        }
        bootstrap {
            disable: false
        }
    }
????static {
    ????route 1.1.0.0/22 {
????????    next-hop: 10.3.3.2
????????    metric: 1
????    }
????    route 1.1.3.0/24 {
    ????????next-hop: 74.121.138.1
????????    metric: 1
????    }
    }
}
fea {
    unicast-forwarding4 {
        disable: false
        forwarding-entries {
            retain-on-startup: true
            retain-on-shutdown: true
        }
    }
}
interfaces {
    restore-original-config-on-shutdown: false
    interface "eth0.33" {
        description: "data interface"
        disable: false
        discard: false
        unreachable: false
        management: false
        vif eth0.33 {
            disable: false
            address 2.2.2.2 {
                prefix-length: 24
                disable: false
            }
        }
    }
    interface "eth0.512" {
        description: "data interface"
        disable: false
        discard: false
        unreachable: false
        management: false
        vif eth0.512 {
            disable: false
            address 1.1.1.1 {
                prefix-length: 24
                disable: false
            }
        }
    }
}
plumbing {
    mfea4 {
        disable: false
        interface "eth0.33" {
            vif "eth0.33" {
                disable: false
            }
        }
        interface "eth0.512" {
            vif "eth0.512" {
                disable: true
            }
        }
        interface "register_vif" {
             vif "register_vif" {
                 disable: false
             }
        }
    }
}
rtrmgr {
    load-file-command: "fetch"
    load-file-command-args: "-o"
    load-ftp-command: "fetch"
    load-ftp-command-args: "-o"
    load-http-command: "fetch"
    load-http-command-args: "-o"
    load-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    load-tftp-command-args: ""
    save-file-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-file-command-args: ""
    save-ftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-ftp-command-args: ""
    save-http-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-http-command-args: ""
    save-tftp-command: "sh -c 'echo Not implemented 1>&2 && exit 1'"
    save-tftp-command-args: ""
}
----8<----




On Fri, Feb 25, 2011 at 11:46 AM, Nicholas Schmidt
<nschmidt at mediamath.com> wrote:
> I have provided the configuration and error in my original email. Here it is
> again for those who have missed it. I have read through and configured per
> the Getting Started documentation.
>
> -Nick
>
> Log:
>
> [ 2011/02/24 16:26:54 ?INFO xorp_rtrmgr:3981 RTRMGR +101 module_manager.cc
> execute ] Executing module: firewall (fea/xorp_fea)
> [ 2011/02/24 16:26:58 ?INFO xorp_rtrmgr:3981 RTRMGR +101 module_manager.cc
> execute ] Executing module: fea (fea/xorp_fea)
> [ 2011/02/24 16:27:05 ?INFO xorp_rtrmgr:3981 RTRMGR +101 module_manager.cc
> execute ] Executing module: mfea4 (fea/xorp_fea)
> [ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] Interface added: Vif[eth0.33]
> pif_index: 4 vif_index: 0 addr: 74.121.138.180 subnet: 74.121.138.0/24
> broadcast: 74.121.138.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
> UNDERLYING_VIF_UP MTU: 1500
> [ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] Interface added: Vif[eth0.512]
> pif_index: 5 vif_index: 1 addr: 10.3.3.1 subnet: 10.3.3.0/24 broadcast:
> 10.3.3.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU:
> 1500
> [ 2011/02/24 16:27:05 ?ERROR xorp_fea:3982 MFEA +709 mfea_mrouter.cc
> start_mrt ] setsockopt(MRT_INIT, 1) failed: Address already in use
> [ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] MFEA started
> [ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] Interface enabled Vif[eth0.33]
> pif_index: 4 vif_index: 0 addr: 74.121.138.180 subnet: 74.121.138.0/24
> broadcast: 74.121.138.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
> UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
> [ 2011/02/24 16:27:05 ?ERROR xorp_fea:3982 MFEA +1113 mfea_mrouter.cc
> add_multicast_vif ] setsockopt(MRT_ADD_VIF, vif eth0.33) failed: Address
> already in use
> [ 2011/02/24 16:27:05 ?ERROR xorp_fea:3982 MFEA +1191 mfea_node.cc start_vif
> ] Cannot start vif eth0.33: cannot add the multicast vif to the kernel
> [ 2011/02/24 16:27:05 WARNING xorp_fea XrlMfeaTarget ] Handling method for
> mfea/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot start vif
> eth0.33: cannot add the multicast vif to the kernel
> [ 2011/02/24 16:27:05 ?ERROR xorp_rtrmgr:3981 RTRMGR +691
> master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed
> Cannot start vif eth0.33: cannot add the multicast vif to the kernel
> [ 2011/02/24 16:27:05 ?ERROR xorp_rtrmgr:3981 RTRMGR +261
> master_conf_tree.cc config_done ] Configuration failed: 102 Command failed
> Cannot start vif eth0.33: cannot add the multicast vif to the kernel
> [ 2011/02/24 16:27:05 ?INFO xorp_rtrmgr:3981 RTRMGR +2233 task.cc run_task ]
> No more tasks to run
> [ 2011/02/24 16:27:05 ?INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc
> terminate ] Terminating module: fea
> [ 2011/02/24 16:27:05 ?INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc
> terminate ] Terminating module: firewall
> [ 2011/02/24 16:27:05 ?INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc
> terminate ] Terminating module: interfaces
> [ 2011/02/24 16:27:05 ?INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc
> terminate ] Terminating module: mfea4
> [ 2011/02/24 16:27:05 ?INFO xorp_rtrmgr:3981 RTRMGR +199 module_manager.cc
> terminate ] Killing module: mfea4
> [ 2011/02/24 16:27:05 ?ERROR xorp_rtrmgr:3981 RTRMGR +754 module_manager.cc
> done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 15.
> [ 2011/02/24 16:27:05 ?INFO xorp_rtrmgr:3981 RTRMGR +287 module_manager.cc
> module_exited ] Module killed during shutdown: mfea4
>
> Configuration:
>
> interfaces {
> ????restore-original-config-on-shutdown: false
> ????interface eth0.33 {
> ????description: "data interface"
> ????disable: false
> ????/* default-system-config */
> ????vif eth0.33 {
> ????????disable: false
> ????????address 2.2.2.2 {
> ????????prefix-length: 24
> ????????broadcast: 2.2.2.255
> ????????disable: false
> ????????}
> ????}
> ????}
> ????interface eth0.512 {
> ????description: "data interface"
> ????disable: false
> ????/* default-system-config */
> ????vif eth0.512 {
> ????????disable: false
> ????????address 1.1.1.1 {
> ????????prefix-length: 24
> ????????broadcast: 1.1.1.255
> ????????disable: false
> ????????}
> ????}
> ????}
> }
>
> fea {
> ????unicast-forwarding4 {
> ????????disable: false
> ????}
> }
> protocols {
> ????static {
> ????route 1.1.0.0/22 {
> ????????next-hop: 10.3.3.2
> ????????metric: 1
> ????}
> ????route 1.1.3.0/24 {
> ????????next-hop: 74.121.138.1
> ????????metric: 1
> ????}
> ???}
> }
>
> plumbing {
> ????mfea4 {
> ????disable: false
> ????interface eth0.33 {
> ????????vif eth0.33 {
> ????????disable: false
> ????????}
> ????}
> ????interface eth0.512 {
> ????????vif eth0.512 {
> ????????disable: true
> ????????}
> ????}
> ????interface register_vif {
> ????????vif register_vif {
> ????????/* Note: this vif should be always enabled */
> ????????disable: false
> ????????}
> ????}
> ????traceoptions {
> ????????flag all {
> ????????disable: false
> ????????}
> ????}
> ????}
> }
>
>
> protocols {
> ????pimsm4 {
> ????disable: false
> ????interface eth0.33 {
> ????????vif eth0.33 {
> ????????disable: false
> ????????/* enable-ip-router-alert-option-check: false */
> ????????/* dr-priority: 1 */
> ????????/* hello-period: 30 */
> ????????/* hello-triggered-delay: 5 */
> ????????}
> ????}
> ????interface eth0.512 {
> ????????vif eth0.512 {
> ????????disable: false
> ????????/* enable-ip-router-alert-option-check: false */
> ????????/* dr-priority: 1 */
> ????????/* hello-period: 30 */
> ????????/* hello-triggered-delay: 5 */
> ????????}
> ????}
> ????interface register_vif {
> ????????vif register_vif {
> ????????/* Note: this vif should be always enabled */
> ????????disable: false
> ????????}
> ????}
>
> ????static-rps {
> ????????rp 6.6.6.6 {
> ????????group-prefix 224.0.0.0/4 {
> ????????????/* rp-priority: 192 */
> ????????????/* hash-mask-len: 30 */
> ????????}
> ????????}
> ????}
>
> ????switch-to-spt-threshold {
> ????????/* approx. 1K bytes/s (10Kbps) threshold */
> ????????disable: false
> ????????interval: 100
> ????????bytes: 102400
> ????}
>
> ????traceoptions {
> ????????flag all {
> ????????disable: false
> ????????}
> ????}
> ???}
> }
> protocols {
> ????igmp {
> ????disable: false
> ????interface eth0.33 {
> ????????vif eth0.33 {
> ????????disable: false
> ????????/* version: 2 */
> ????????/* enable-ip-router-alert-option-check: false */
> ????????/* query-interval: 125 */
> ????????/* query-last-member-interval: 1 */
> ????????/* query-response-interval: 10 */
> ????????/* robust-count: 2 */
> ????????}
> ????}
> ????interface eth0.512 {
> ????????vif eth0.512 {
> ????????disable: false
> ????????/* version: 2 */
> ????????/* enable-ip-router-alert-option-check: false */
> ????????/* query-interval: 125 */
> ????????/* query-last-member-interval: 1 */
> ????????/* query-response-interval: 10 */
> ????????/* robust-count: 2 */
> ????????}
> ????}
> ????traceoptions {
> ????????flag all {
> ????????disable: false
> ????????}
> ????}
> ????}
> }
>
>
>
>
>
> On 2/25/11 11:41 AM, "Ray Soucy" <rps at maine.edu> wrote:
>
> Hi Nicholas,
>
> We have a pretty large XORP deployment for multicast. ?In our
> experience 90% of problems people run into are configuration issues.
>
> Can you provide us with your XORP configuration? ?Also be sure to
> check that you don't have iptables blocking the traffic.
>
> On Fri, Feb 25, 2011 at 11:32 AM, Nicholas Schmidt
> <nschmidt at mediamath.com> wrote:
>> This is a clean installation of Debian with no routing processes in the
>> background running Kernel 2.6.26-2-amd64 and xorp version 1.6
>>
>> -Nick
>>
>>
>> On 2/24/11 7:23 PM, "Ben Greear" <greearb at candelatech.com> wrote:
>>
>> On 02/24/2011 01:30 PM, Nicholas Schmidt wrote:
>>> Greetings list,
>>> I am attempting to run xorp for the first time to satisfy some multicast
>>> routing needs that is not currently supported by our hardware vendor. I
>>> have
>>> attempted
>>> to write the simplist possible configuration for my needs based on the
>>> guides provided by I receive an MFEA4 error when attempting to launch the
>>> application.
>>> Any help would be appreciated.
>>
>> Are you running any other routing daemons, or maybe some xorp processes
>> running in the background?
>>
>> What xorp version?
>>
>> What kernel version?
>>
>> Thanks,
>> Ben
>>
>> --
>> Ben Greear <greearb at candelatech.com>
>> Candela Technologies Inc ?http://www.candelatech.com
>>
>>
>> _______________________________________________
>> Xorp-users mailing list
>> Xorp-users at xorp.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>>
>>
>
>
>
> --
> Ray Soucy
>
> Epic Communications Specialist
>
> Phone: +1 (207) 561-3526
>
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From greearb at candelatech.com  Fri Feb 25 12:43:31 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 25 Feb 2011 12:43:31 -0800
Subject: [Xorp-users] Windows build of xorp.ct for testing.
Message-ID: <4D681473.4070701@candelatech.com>

I have done no testing on this, but the xorp_rtrmg.exe will
at least launch enough to complain about config files.

Basically, I reverted the patch from 2009 that removed
win32 support and hacked on it till it would compile
under mingw.

http://www.candelatech.com/~greearb/xorp_win32.zip

If anyone gives this a try, I'm interested in knowing
how it works (or not).

I'll push the code to xorp.ct after I get some testing
completed and make sure that I didn't obviously break
xorp under Linux.

Thanks,
Ben

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


From greearb at candelatech.com  Fri Feb 25 13:31:09 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 25 Feb 2011 13:31:09 -0800
Subject: [Xorp-users] [Xorp-hackers] Windows build of xorp.ct for
	testing.
In-Reply-To: <4D681473.4070701@candelatech.com>
References: <4D681473.4070701@candelatech.com>
Message-ID: <4D681F9D.90608@candelatech.com>

On 02/25/2011 12:43 PM, Ben Greear wrote:
> I have done no testing on this, but the xorp_rtrmg.exe will
> at least launch enough to complain about config files.
>
> Basically, I reverted the patch from 2009 that removed
> win32 support and hacked on it till it would compile
> under mingw.
>
> http://www.candelatech.com/~greearb/xorp_win32.zip
>
> If anyone gives this a try, I'm interested in knowing
> how it works (or not).
>
> I'll push the code to xorp.ct after I get some testing
> completed and make sure that I didn't obviously break
> xorp under Linux.

Ahh, looks like I have some more work to do...it looks
in the wrong place for templates, etc...

Will post when I get that fixed..

Thanks,
Ben

>
> Thanks,
> Ben
>


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


From rps at maine.edu  Fri Feb 25 15:42:00 2011
From: rps at maine.edu (Ray Soucy)
Date: Fri, 25 Feb 2011 18:42:00 -0500
Subject: [Xorp-users] XORP on Windows
In-Reply-To: <3554AFFDD1D9B842BD71DCA70CF35CB8011B017A@usnjpar1blex05.us.ad.irmc.com>
References: <AcvL/IDU0hpQNDzPRQ27eA6ED1DO8gAcdyRAAAAjO1A=>
	<3554AFFDD1D9B842BD71DCA70CF35CB8011B017A@usnjpar1blex05.us.ad.irmc.com>
Message-ID: <AANLkTikpHd-YU450exU3=WE9M0QwJbg8g3SCuFgD7FsR@mail.gmail.com>

I suspect it will use the internal ID which would look like
"{EB736B76-9090-4C28-8FC5-42118B4328EF}"

To find it, you'll need to go into the registry and navigate to:
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\"
Then expand each key in the tree and look for a "Connection\Name"
entry that is the name of the interface you want.

For me the full key was:

"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\{EB736B76-9090-4C28-8FC5-42118B4328EF}\Connection\Name"
= "Local Area Connection".

That might not be the case, but other *nix ports for Windows seem to
work like this.

Might be worth writing a VB script or something to list interface IDs
and include it with the Windows copy of XORP, assuming it even runs at
all.

I think it's time you embrace Linux ;-)

On Mon, Feb 14, 2011 at 12:45 PM, Sharma2, Sandeep
<sandeep.sharma2 at iqor.com> wrote:
>
>
> Hi,
>
>
>
> I am trying to run XORP 1.6 on multiple platforms. I was able to get it to
> run quite easily on Centos Linux 2.6.18 but ran into difficulties on Windows
> Server 2008. I could not figure out the correct way to name the network
> interfaces in the boot config file. Unfortunately I could not get
> show_interfaces to run either.
>
>
>
> Unsuccessfully tried:
>
> Unix style interface names e.g. eth0 and ge0
>
> Windows ipconfig syle interface names e.g. ?Local Area Connection 2?
>
>
>
> Can anyone point out the correct naming scheme for network interfaces on
> Windows ?
>
>
>
> Thanks,
>
> Sandeep
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From greearb at candelatech.com  Fri Feb 25 15:51:53 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 25 Feb 2011 15:51:53 -0800
Subject: [Xorp-users] [Xorp-hackers] Windows build of xorp.ct for
	testing.
In-Reply-To: <4D681F9D.90608@candelatech.com>
References: <4D681473.4070701@candelatech.com> <4D681F9D.90608@candelatech.com>
Message-ID: <4D684099.3090702@candelatech.com>

On 02/25/2011 01:31 PM, Ben Greear wrote:
> On 02/25/2011 12:43 PM, Ben Greear wrote:
>> I have done no testing on this, but the xorp_rtrmg.exe will
>> at least launch enough to complain about config files.
>>
>> Basically, I reverted the patch from 2009 that removed
>> win32 support and hacked on it till it would compile
>> under mingw.
>>
>> http://www.candelatech.com/~greearb/xorp_win32.zip
>>
>> If anyone gives this a try, I'm interested in knowing
>> how it works (or not).
>>
>> I'll push the code to xorp.ct after I get some testing
>> completed and make sure that I didn't obviously break
>> xorp under Linux.
>
> Ahh, looks like I have some more work to do...it looks
> in the wrong place for templates, etc...
>
> Will post when I get that fixed..

Ok, it's working better now.   OSPF starts, but I haven't
tested if it actually talks with other OSPF servers, etc.

File is at same location:
http://www.candelatech.com/~greearb/xorp_win32.zip


Here's how I started it:

    To run xorp on windows:

    *  Unzip it somewhere
    *  Change to the xorp/sbin directory
    *  Start router-mgr:
      set XORP_PF=t
      set XORP_ROOT=..
      xorp_rtrmgr.exe -c config.boot.t xt -t ..\share\xorp\templates -m ..\lib\xorp\bin

    * In another window, start xorpsh:
      set XORP_PF=t
      set XORP_ROOT=..
      xorpsh

Here's a sample config file (Original courtesy of Asif @ iQor)

C:\xorp_win32\xorp\sbin>more c:\config.boot.txt

interfaces {
         interface "Local Area Connection 7" {
                 disable: false
                 vif "Local Area Connection 7" {
                         disable: false
                         address 10.2.46.190 {
                                 prefix-length: 24
                                 broadcast: 10.2.46.255
                                 disable: false
                         }
                 }
         }
         interface "Local Area Connection 6" {
                 disable: false
                 vif "Local Area Connection 6" {
                         disable: false
                         address 10.4.5.6 {
                                 prefix-length: 24
                                 disable: false
                 }
         }
    }
}
fea {
         unicast-forwarding4 {
                 disable: false
         }
}

protocols {
         ospf4 {
                 router-id : 10.2.46.190
                 area 0.0.0.0 {
                         interface "Local Area Connection 7" {
                                 vif "Local Area Connection 7" {
                                         address 10.2.46.190 {
                                                 hello-interval: 1
                                                 router-dead-interval: 4
                                         }
                                 }
                         }
                         interface "Local Area Connection 6" {
                                 vif "Local Area Connection 6" {
                                         address 10.4.5.6 {
                                         }
                                 }
                         }
                 }

         }
}


Thanks,
Ben

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


From greearb at candelatech.com  Fri Feb 25 15:57:30 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 25 Feb 2011 15:57:30 -0800
Subject: [Xorp-users] XORP on Windows
In-Reply-To: <AANLkTikpHd-YU450exU3=WE9M0QwJbg8g3SCuFgD7FsR@mail.gmail.com>
References: <AcvL/IDU0hpQNDzPRQ27eA6ED1DO8gAcdyRAAAAjO1A=>	<3554AFFDD1D9B842BD71DCA70CF35CB8011B017A@usnjpar1blex05.us.ad.irmc.com>
	<AANLkTikpHd-YU450exU3=WE9M0QwJbg8g3SCuFgD7FsR@mail.gmail.com>
Message-ID: <4D6841EA.2030305@candelatech.com>

On 02/25/2011 03:42 PM, Ray Soucy wrote:
> I suspect it will use the internal ID which would look like
> "{EB736B76-9090-4C28-8FC5-42118B4328EF}"

It's more like "Local Area Connection 7" (at least in the xorp.ct
code that I'm working on..see my prev post about xorp.ct on windows).

Thanks,
Ben

PS.  Linux is still going to be the way to go unless you absolutely
have to use Windows:  I have no tools to diagnose backtraces and
such on Windows...so it's not going to be easy to debug any serious
bugs...

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


From greearb at candelatech.com  Fri Feb 25 16:17:50 2011
From: greearb at candelatech.com (Ben Greear)
Date: Fri, 25 Feb 2011 16:17:50 -0800
Subject: [Xorp-users] [Xorp-hackers] Windows build of xorp.ct for
	testing.
In-Reply-To: <4D684099.3090702@candelatech.com>
References: <4D681473.4070701@candelatech.com> <4D681F9D.90608@candelatech.com>
	<4D684099.3090702@candelatech.com>
Message-ID: <4D6846AE.1010205@candelatech.com>

On 02/25/2011 03:51 PM, Ben Greear wrote:
> On 02/25/2011 01:31 PM, Ben Greear wrote:
>> On 02/25/2011 12:43 PM, Ben Greear wrote:
>>> I have done no testing on this, but the xorp_rtrmg.exe will
>>> at least launch enough to complain about config files.
>>>
>>> Basically, I reverted the patch from 2009 that removed
>>> win32 support and hacked on it till it would compile
>>> under mingw.
>>>
>>> http://www.candelatech.com/~greearb/xorp_win32.zip
>>>
>>> If anyone gives this a try, I'm interested in knowing
>>> how it works (or not).
>>>
>>> I'll push the code to xorp.ct after I get some testing
>>> completed and make sure that I didn't obviously break
>>> xorp under Linux.
>>
>> Ahh, looks like I have some more work to do...it looks
>> in the wrong place for templates, etc...
>>
>> Will post when I get that fixed..
>
> Ok, it's working better now.   OSPF starts, but I haven't
> tested if it actually talks with other OSPF servers, etc.

I did a quick test with OSPF, and it talks to another
xorp on Linux and exchanges routes.  So, I think it's
somewhat usable now...

Thanks,
Ben

>
> File is at same location:
> http://www.candelatech.com/~greearb/xorp_win32.zip
>
>
> Here's how I started it:
>
>      To run xorp on windows:
>
>      *  Unzip it somewhere
>      *  Change to the xorp/sbin directory
>      *  Start router-mgr:
>        set XORP_PF=t
>        set XORP_ROOT=..
>        xorp_rtrmgr.exe -c config.boot.t xt -t ..\share\xorp\templates -m ..\lib\xorp\bin
>
>      * In another window, start xorpsh:
>        set XORP_PF=t
>        set XORP_ROOT=..
>        xorpsh
>
> Here's a sample config file (Original courtesy of Asif @ iQor)
>
> C:\xorp_win32\xorp\sbin>more c:\config.boot.txt
>
> interfaces {
>           interface "Local Area Connection 7" {
>                   disable: false
>                   vif "Local Area Connection 7" {
>                           disable: false
>                           address 10.2.46.190 {
>                                   prefix-length: 24
>                                   broadcast: 10.2.46.255
>                                   disable: false
>                           }
>                   }
>           }
>           interface "Local Area Connection 6" {
>                   disable: false
>                   vif "Local Area Connection 6" {
>                           disable: false
>                           address 10.4.5.6 {
>                                   prefix-length: 24
>                                   disable: false
>                   }
>           }
>      }
> }
> fea {
>           unicast-forwarding4 {
>                   disable: false
>           }
> }
>
> protocols {
>           ospf4 {
>                   router-id : 10.2.46.190
>                   area 0.0.0.0 {
>                           interface "Local Area Connection 7" {
>                                   vif "Local Area Connection 7" {
>                                           address 10.2.46.190 {
>                                                   hello-interval: 1
>                                                   router-dead-interval: 4
>                                           }
>                                   }
>                           }
>                           interface "Local Area Connection 6" {
>                                   vif "Local Area Connection 6" {
>                                           address 10.4.5.6 {
>                                           }
>                                   }
>                           }
>                   }
>
>           }
> }
>
>
> Thanks,
> Ben
>


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


From pierre.lepropre at student.ulg.ac.be  Sat Feb 26 05:15:58 2011
From: pierre.lepropre at student.ulg.ac.be (Pierre Lepropre)
Date: Sat, 26 Feb 2011 14:15:58 +0100
Subject: [Xorp-users] Xorp documentation
In-Reply-To: <4D66FD1C.8030602@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
	<4D59B4B7.7060603@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>
	<4D5AD437.9000607@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>
	<4D5ADA52.8000108@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>
	<AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>
	<1298580928.2186.5.camel@pierre-T500>
	<AANLkTi=bvtGzts5TUui9o35ggiwkZtb9x+59d6pLsEok@mail.gmail.! com>
	<4D66FD1C.8030602@candelatech.com>
Message-ID: <1298726158.2423.24.camel@pierre-T500>

Ben,

As I was telling Ray, the wiki we're using is kind of an internal thing
and vastly incomplete (and maybe inaccurate for some stuff but I hope
not...).

Right now, we're 2 people working on it but I think I will be alone on
this in 2 weeks top. The foundations were created and written between
Xorp 1.6 and Xorp CT 1.7 so there are still a lot of information missing
for the basic moves and I try to update them as much as possible and
make it "noob-proof". Actually, I've been involved with XORP for only 3
months, without achieving anything great so far, so I'm a total noob
right now.

As far as I'm concerned, everybody is welcomed to take a look and why
not make suggestions ? 
Nevertheless, I have to warn everybody: we're using XORP as part of a
European project (ECODE) and so, some information on it isn't exactly
relevant for the common XORP-user. Not much, though.

Currently, you can assume I'm the only guy maintaining it for the next
couple of months and as it is not exactly in my master thesis objectives
to manage something like that and its users, I do NOT have enough
time/credentials to regulate everything going in and out of there. In
one word, here is the thing: everybody can read and enjoy although I'm
gonna have to restrict writing access to a small set of people. 

I guess the best subset of people would be the most experienced ones
with XORP (namely you, Ben ;-) ) if they wanna come in. I don't know,
it's kinda up to you guys. At the end of my master thesis, I personally
guarantee you that I will make everything in my power to transfer you
the whole content to upload it somewhere else.

Here is the URL in case anybody is interested:
http://queen.run.montefiore.ulg.ac.be/~willemaers/doku-xorp/doku.php

Please, Ben, do NOT put that URL on the xorp website, at least not yet.
I'd like to see how the community responds to that initiative and talk
about it with my direct supervisor.

Regarding the documentation itself, I think most of it should be written
back from square one. Fixing things that have been fixed and then
refixed for so much time doesn't lead to an accurate and readable
documentation. Don't get wrong heh, I'm not blaming anyone on this, the
1.6 documentation was already outdated at the time they released the
version.

Regards,

Pierre.
On Thu, 2011-02-24 at 16:51 -0800, Ben Greear wrote:
> 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
> 
> 



From diego360xen at gmail.com  Sat Feb 26 08:57:58 2011
From: diego360xen at gmail.com (=?ISO-8859-1?Q?Diego_Augusto_Pinzon_Carre=F1o?=)
Date: Sat, 26 Feb 2011 11:57:58 -0500
Subject: [Xorp-users] contributing to information on XORP
Message-ID: <AANLkTik4ZZ+XQc0hxfnJr=R+tmNEudjuCnP-_ydtGKge@mail.gmail.com>

hi, Pierre

 i am interested in contributing to information on XORP,
I've done so far is to test XORP, unicast protocols,
 in a mini network of four virtual machines using virtualbox and
tunclt virtual interfaces, I'm also working on my final project for
graduation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110226/1f4c32eb/attachment.html 

From greearb at candelatech.com  Sat Feb 26 13:20:30 2011
From: greearb at candelatech.com (Ben Greear)
Date: Sat, 26 Feb 2011 13:20:30 -0800
Subject: [Xorp-users] Xorp documentation
In-Reply-To: <1298726158.2423.24.camel@pierre-T500>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>	
	<4D598F5B.1000405@candelatech.com>	
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>	
	<4D59AA1E.7000608@candelatech.com>	
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>	
	<4D59AF8A.4040502@candelatech.com>	
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>	
	<4D59B4B7.7060603@candelatech.com>	
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>	
	<4D5AD437.9000607@candelatech.com>	
	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>	
	<4D5ADA52.8000108@candelatech.com>	
	<65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>	
	<AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>	
	<1298580928.2186.5.camel@pierre-T500>	
	<AANLkTi=bvtGzts5TUui9o35ggiwkZtb9x+59d6pLsEok@mail.gmail.!
	com>	 <4D66FD1C.8030602@candelatech.com>
	<1298726158.2423.24.camel@pierre-T500>
Message-ID: <4D696E9E.9030808@candelatech.com>

On 02/26/2011 05:15 AM, Pierre Lepropre wrote:
> Ben,
>
> As I was telling Ray, the wiki we're using is kind of an internal thing
> and vastly incomplete (and maybe inaccurate for some stuff but I hope
> not...).

Looks good!  Your presentation slides are particularly nice.  Only problem
I noticed is that they have SNMP listed in them, and it's been gone
from Xorp for some time (and unlikely to ever return).

> I guess the best subset of people would be the most experienced ones
> with XORP (namely you, Ben ;-) ) if they wanna come in. I don't know,
> it's kinda up to you guys. At the end of my master thesis, I personally
> guarantee you that I will make everything in my power to transfer you
> the whole content to upload it somewhere else.
>
> Here is the URL in case anybody is interested:
> http://queen.run.montefiore.ulg.ac.be/~willemaers/doku-xorp/doku.php
>
> Please, Ben, do NOT put that URL on the xorp website, at least not yet.
> I'd like to see how the community responds to that initiative and talk
> about it with my direct supervisor.
>
> Regarding the documentation itself, I think most of it should be written
> back from square one. Fixing things that have been fixed and then
> refixed for so much time doesn't lead to an accurate and readable
> documentation. Don't get wrong heh, I'm not blaming anyone on this, the
> 1.6 documentation was already outdated at the time they released the
> version.

It always seems easier (and more fun) to do things from scratch, but often taking
the time to do incremental improvements produces more long-term
gain.  (You can get a re-write 90% done, at large effort, and
run out of time/interest, and the end result is still less
useful than the original funky documentation.)

I'm personally not so interested in poking content into a wiki that I'm
not 100% certain can be freely copied (ie, what if your project leaders
decide to suddenly restrict access, or just turn off the servers).
I would like to add your slide-show to the xorp.ct tree and web site
if/when you give permission.  And I'll be happy to link to your page
when you are ready.

For the existing documentation, it's .tex files and found in
xorp.ct/docs/*  I don't particularly know latex or ever tried to learn
it, but it is not difficult to make changes to the existing text.
You can build the postscript & pdf files with scons from the docs dir.

The web docs are at:
xorp.ct/www/html_src

You 'compile' the web pages by typing 'make'
in xorp.ct/www
There is a script in xorp.ct/www/scripts/ that generates
the html from the source pages.

If anyone makes changes they'd like incorporated upstream, post
the diffs to the mailing list and/or send them to me directly.

Thanks,
Ben

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


From rps at maine.edu  Sat Feb 26 14:07:41 2011
From: rps at maine.edu (Ray Soucy)
Date: Sat, 26 Feb 2011 17:07:41 -0500
Subject: [Xorp-users] Xorp documentation
In-Reply-To: <4D696E9E.9030808@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
	<4D59B4B7.7060603@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>
	<4D5AD437.9000607@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>
	<4D5ADA52.8000108@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>
	<AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>
	<1298580928.2186.5.camel@pierre-T500>
	<4D66FD1C.8030602@candelatech.com>
	<1298726158.2423.24.camel@pierre-T500>
	<4D696E9E.9030808@candelatech.com>
Message-ID: <AANLkTino9MHAcUadvTYm5Fny+a5Nu0jtppz-FoToSuhp@mail.gmail.com>

For what its worth, I still have a pretty large XORP 1.6 deployment
and wanted a place to throw everything 1.6-related until I can migrate
to XORP.CT or we see XORP proper actively developed again.

I've included instructions for building on Ubuntu Server LTS 10.4
which should be easily adapted to your Linux of choice, along with
patches necessary to compile XORP in a post-GCC 4.4 world (along with
the Heiko patch)   I've also thrown up configuration examples
previously posted here.

http://www.soucy.org/xorp/

On a side note one of the things that's kept me from moving to CT has
been the configuration file syntax has changed, so it's now a manual
process to move over for 100+ devices.

I haven't had time to look through the archive.  But if anyone knows
of any "must have" patches I should include let me know and I'll add
them provided they're bug fixes and not functionality changes.

On Sat, Feb 26, 2011 at 4:20 PM, Ben Greear <greearb at candelatech.com> wrote:
> On 02/26/2011 05:15 AM, Pierre Lepropre wrote:
>>
>> Ben,
>>
>> As I was telling Ray, the wiki we're using is kind of an internal thing
>> and vastly incomplete (and maybe inaccurate for some stuff but I hope
>> not...).
>
> Looks good! ?Your presentation slides are particularly nice. ?Only problem
> I noticed is that they have SNMP listed in them, and it's been gone
> from Xorp for some time (and unlikely to ever return).
>
>> I guess the best subset of people would be the most experienced ones
>> with XORP (namely you, Ben ;-) ) if they wanna come in. I don't know,
>> it's kinda up to you guys. At the end of my master thesis, I personally
>> guarantee you that I will make everything in my power to transfer you
>> the whole content to upload it somewhere else.
>>
>> Here is the URL in case anybody is interested:
>> http://queen.run.montefiore.ulg.ac.be/~willemaers/doku-xorp/doku.php
>>
>> Please, Ben, do NOT put that URL on the xorp website, at least not yet.
>> I'd like to see how the community responds to that initiative and talk
>> about it with my direct supervisor.
>>
>> Regarding the documentation itself, I think most of it should be written
>> back from square one. Fixing things that have been fixed and then
>> refixed for so much time doesn't lead to an accurate and readable
>> documentation. Don't get wrong heh, I'm not blaming anyone on this, the
>> 1.6 documentation was already outdated at the time they released the
>> version.
>
> It always seems easier (and more fun) to do things from scratch, but often
> taking
> the time to do incremental improvements produces more long-term
> gain. ?(You can get a re-write 90% done, at large effort, and
> run out of time/interest, and the end result is still less
> useful than the original funky documentation.)
>
> I'm personally not so interested in poking content into a wiki that I'm
> not 100% certain can be freely copied (ie, what if your project leaders
> decide to suddenly restrict access, or just turn off the servers).
> I would like to add your slide-show to the xorp.ct tree and web site
> if/when you give permission. ?And I'll be happy to link to your page
> when you are ready.
>
> For the existing documentation, it's .tex files and found in
> xorp.ct/docs/* ?I don't particularly know latex or ever tried to learn
> it, but it is not difficult to make changes to the existing text.
> You can build the postscript & pdf files with scons from the docs dir.
>
> The web docs are at:
> xorp.ct/www/html_src
>
> You 'compile' the web pages by typing 'make'
> in xorp.ct/www
> There is a script in xorp.ct/www/scripts/ that generates
> the html from the source pages.
>
> If anyone makes changes they'd like incorporated upstream, post
> the diffs to the mailing list and/or send them to me directly.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From greearb at candelatech.com  Sat Feb 26 14:16:55 2011
From: greearb at candelatech.com (Ben Greear)
Date: Sat, 26 Feb 2011 14:16:55 -0800
Subject: [Xorp-users] Xorp documentation
In-Reply-To: <AANLkTino9MHAcUadvTYm5Fny+a5Nu0jtppz-FoToSuhp@mail.gmail.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>	<4D598F5B.1000405@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>	<4D59AA1E.7000608@candelatech.com>	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>	<4D59AF8A.4040502@candelatech.com>	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>	<4D59B4B7.7060603@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>	<4D5AD437.9000607@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>	<4D5ADA52.8000108@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>	<AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>	<1298580928.2186.5.camel@pierre-T500>	<4D66FD1C.8030602@candelatech.com>	<1298726158.2423.24.camel@pierre-T500>	<4D696E9E.9030808@candelatech.com>
	<AANLkTino9MHAcUadvTYm5Fny+a5Nu0jtppz-FoToSuhp@mail.gmail.c! om>
Message-ID: <4D697BD7.2070606@candelatech.com>

On 02/26/2011 02:07 PM, Ray Soucy wrote:
> For what its worth, I still have a pretty large XORP 1.6 deployment
> and wanted a place to throw everything 1.6-related until I can migrate
> to XORP.CT or we see XORP proper actively developed again.
>
> I've included instructions for building on Ubuntu Server LTS 10.4
> which should be easily adapted to your Linux of choice, along with
> patches necessary to compile XORP in a post-GCC 4.4 world (along with
> the Heiko patch)   I've also thrown up configuration examples
> previously posted here.
>
> http://www.soucy.org/xorp/
>
> On a side note one of the things that's kept me from moving to CT has
> been the configuration file syntax has changed, so it's now a manual
> process to move over for 100+ devices.

Do you know what change in particular is causing trouble?

> I haven't had time to look through the archive.  But if anyone knows
> of any "must have" patches I should include let me know and I'll add
> them provided they're bug fixes and not functionality changes.

If your current solution is stable, then I wouldn't go adding
patches.  Most of my patches cover race conditions around adding/deleting
interfaces and such.  If you have such an environment...xorp.ct should
be noticeably better.  But, for a well-behaved static environment,
xorp 1.6 is probably fine.

Thanks,
Ben

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


From rps at maine.edu  Sat Feb 26 14:24:25 2011
From: rps at maine.edu (Ray Soucy)
Date: Sat, 26 Feb 2011 17:24:25 -0500
Subject: [Xorp-users] Xorp documentation
In-Reply-To: <4D697BD7.2070606@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
	<4D59B4B7.7060603@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>
	<4D5AD437.9000607@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>
	<4D5ADA52.8000108@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>
	<AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>
	<1298580928.2186.5.camel@pierre-T500>
	<4D66FD1C.8030602@candelatech.com>
	<1298726158.2423.24.camel@pierre-T500>
	<4D696E9E.9030808@candelatech.com>
	<AANLkTino9MHAcUadvTYm5Fny+a5Nu0jtppz-FoToSuhp@mail.gmail.com>
	<4D697BD7.2070606@candelatech.com>
Message-ID: <AANLkTi=Knsp_zSAds3a-934EL1v43UOMZpj4YrGdXRKF@mail.gmail.com>

Last time I checked it was just the configuration file header.

On Sat, Feb 26, 2011 at 5:16 PM, Ben Greear <greearb at candelatech.com> wrote:
> On 02/26/2011 02:07 PM, Ray Soucy wrote:
>>
>> For what its worth, I still have a pretty large XORP 1.6 deployment
>> and wanted a place to throw everything 1.6-related until I can migrate
>> to XORP.CT or we see XORP proper actively developed again.
>>
>> I've included instructions for building on Ubuntu Server LTS 10.4
>> which should be easily adapted to your Linux of choice, along with
>> patches necessary to compile XORP in a post-GCC 4.4 world (along with
>> the Heiko patch) ? I've also thrown up configuration examples
>> previously posted here.
>>
>> http://www.soucy.org/xorp/
>>
>> On a side note one of the things that's kept me from moving to CT has
>> been the configuration file syntax has changed, so it's now a manual
>> process to move over for 100+ devices.
>
> Do you know what change in particular is causing trouble?
>
>> I haven't had time to look through the archive. ?But if anyone knows
>> of any "must have" patches I should include let me know and I'll add
>> them provided they're bug fixes and not functionality changes.
>
> If your current solution is stable, then I wouldn't go adding
> patches. ?Most of my patches cover race conditions around adding/deleting
> interfaces and such. ?If you have such an environment...xorp.ct should
> be noticeably better. ?But, for a well-behaved static environment,
> xorp 1.6 is probably fine.
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc ?http://www.candelatech.com
>



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/


From pierre.lepropre at student.ulg.ac.be  Sun Feb 27 01:14:29 2011
From: pierre.lepropre at student.ulg.ac.be (Pierre Lepropre)
Date: Sun, 27 Feb 2011 10:14:29 +0100
Subject: [Xorp-users] Xorp documentation
In-Reply-To: <4D696E9E.9030808@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
	<4D59B4B7.7060603@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>
	<4D5AD437.9000607@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>
	<4D5ADA52.8000108@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>
	<AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>
	<1298580928.2186.5.camel@pierre-T500>
	<AANLkTi=bvtGzts5TUui9o35ggiwkZtb9x+59d6pLsEok@mail.gmail.! com>
	<4D66FD1C.8030602@candelatech.com>
	<1298726158.2423.24.camel@pierre-T500>
	<4D696E9E.9030808@candelatech.com>
Message-ID: <1298798069.2407.9.camel@pierre-T500>

Ben,

> 
> It always seems easier (and more fun) to do things from scratch, but often taking
> the time to do incremental improvements produces more long-term
> gain.  (You can get a re-write 90% done, at large effort, and
> run out of time/interest, and the end result is still less
> useful than the original funky documentation.)
> 

I know: it's easier said than done. The only thing you have to be aware
of: except the most experienced people in XORP, nobody could be able to
do incremental changes in the current documentation as *every* piece of
feature has to be overlooked, the SNMP stuff you just told me is a great
example of that !

> I'm personally not so interested in poking content into a wiki that I'm
> not 100% certain can be freely copied (ie, what if your project leaders
> decide to suddenly restrict access, or just turn off the servers).
> I would like to add your slide-show to the xorp.ct tree and web site
> if/when you give permission.  And I'll be happy to link to your page
> when you are ready.

Ben, we are not a private company but a university. Every piece of work
we would be doing, in such hypothetical conditions, would be with and
for the whole community. Shutting down servers isn't exactly our policy
(actually, you'd be surprised of what still runs out there...).

But if you're afraid of that: why not creating a wiki at CandelaTech or
at some other place neutral where all your fears could be dismissed and
your hopes fulfilled ? I'd be more than happy to give you our whole
current content as a basis to start from.

> For the existing documentation, it's .tex files and found in
> xorp.ct/docs/*  I don't particularly know latex or ever tried to learn
> it, but it is not difficult to make changes to the existing text.
> You can build the postscript & pdf files with scons from the docs dir.

LaTeX isn't that hard but can be a little bit touchy at the beginning
(like XORP ;-) ). The thing is, I don't think it would be really
appropriate to directly modify these pieces of documentation.

In my mind, the LaTeX documentation should be updated with every major
release and in the meanwhile, all the suggestions should be brought to
something more likely to bring people in, as a wiki.

The slides you were referring to are not my own creation so I'm gonna
talk about it with my supervisor, and maybe I could get you the source
files. I don't think there's gonna be any problem with that.

Regards,

Pierre.


From greearb at candelatech.com  Sun Feb 27 08:52:17 2011
From: greearb at candelatech.com (Ben Greear)
Date: Sun, 27 Feb 2011 08:52:17 -0800
Subject: [Xorp-users] Xorp documentation
In-Reply-To: <1298798069.2407.9.camel@pierre-T500>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>	
	<4D59AA1E.7000608@candelatech.com>	
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>	
	<4D59AF8A.4040502@candelatech.com>	
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>	
	<4D59B4B7.7060603@candelatech.com>	
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>	
	<4D5AD437.9000607@candelatech.com>	
	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>	
	<4D5ADA52.8000108@candelatech.com>	
	<65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>	
	<AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>	
	<1298580928.2186.5.camel@pierre-T500>	
	<AANLkTi=bvtGzts5TUui9o35ggiwkZtb9x+59d6pLsEok@mail.gmail.!
	com>	 <4D66FD1C.8030602@candelatech.com>
	<1298726158.2423.24.camel@pierre-T500>	
	<4D696E9E.9030808@candelatech.com>
	<1298798069.2407.9.camel@pierre-T500>
Message-ID: <4D6A8141.2020200@candelatech.com>

On 02/27/2011 01:14 AM, Pierre Lepropre wrote:
> Ben,
>
>>
>> It always seems easier (and more fun) to do things from scratch, but often taking
>> the time to do incremental improvements produces more long-term
>> gain.  (You can get a re-write 90% done, at large effort, and
>> run out of time/interest, and the end result is still less
>> useful than the original funky documentation.)
>>
>
> I know: it's easier said than done. The only thing you have to be aware
> of: except the most experienced people in XORP, nobody could be able to
> do incremental changes in the current documentation as *every* piece of
> feature has to be overlooked, the SNMP stuff you just told me is a great
> example of that !

Well, don't overestimate my own knowledge of xorp.  It's a huge project
and there is lots I don't know myself, especially about the more interesting
configuration options for various routing protocols, etc.

>> I'm personally not so interested in poking content into a wiki that I'm
>> not 100% certain can be freely copied (ie, what if your project leaders
>> decide to suddenly restrict access, or just turn off the servers).
>> I would like to add your slide-show to the xorp.ct tree and web site
>> if/when you give permission.  And I'll be happy to link to your page
>> when you are ready.
>
> Ben, we are not a private company but a university. Every piece of work
> we would be doing, in such hypothetical conditions, would be with and
> for the whole community. Shutting down servers isn't exactly our policy
> (actually, you'd be surprised of what still runs out there...).
>
> But if you're afraid of that: why not creating a wiki at CandelaTech or
> at some other place neutral where all your fears could be dismissed and
> your hopes fulfilled ? I'd be more than happy to give you our whole
> current content as a basis to start from.

I did a quick read on 'doku', and it seems it stores it's source
in flat text files.  Maybe we could just periodically copy them to
some directory in xorp.ct and commit them?  That way we have a
backup that is easy for everyone to share.

>> For the existing documentation, it's .tex files and found in
>> xorp.ct/docs/*  I don't particularly know latex or ever tried to learn
>> it, but it is not difficult to make changes to the existing text.
>> You can build the postscript&  pdf files with scons from the docs dir.
>
> LaTeX isn't that hard but can be a little bit touchy at the beginning
> (like XORP ;-) ). The thing is, I don't think it would be really
> appropriate to directly modify these pieces of documentation.
>
> In my mind, the LaTeX documentation should be updated with every major
> release and in the meanwhile, all the suggestions should be brought to
> something more likely to bring people in, as a wiki.

That sounds nice...but unless someone else is posting patches, that
means it's all on me.  It will scale much better if other folks put
some effort towards the latex.  For that matter, it doesn't have to
be an official patch against the latex...just an email posting with
corrected text and I'll figure out how to get it in latex if that's
what it takes.

> The slides you were referring to are not my own creation so I'm gonna
> talk about it with my supervisor, and maybe I could get you the source
> files. I don't think there's gonna be any problem with that.

Thanks.  Your wiki is very nicely done.  I don't necessarily want to host
it, but I would like to have the backup files within my control.  Then,
if your project ever does cease operations, I could simply install doku
and bring the wiki back online.  That's basically what I had to do with xorp
(forked it to xorp.ct and hosted it on my own site), so I'm a bit touchy
about these things :)

Thanks,
Ben


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


From pierre.lepropre at student.ulg.ac.be  Sun Feb 27 14:54:57 2011
From: pierre.lepropre at student.ulg.ac.be (Pierre Lepropre)
Date: Sun, 27 Feb 2011 23:54:57 +0100
Subject: [Xorp-users] Xorp documentation
In-Reply-To: <4D6A8141.2020200@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
	<4D59B4B7.7060603@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>
	<4D5AD437.9000607@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>
	<4D5ADA52.8000108@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>
	<AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>
	<1298580928.2186.5.camel@pierre-T500>
	<AANLkTi=bvtGzts5TUui9o35ggiwkZtb9x+59d6pLsEok@mail.gmail.! com>
	<4D66FD1C.8030602@candelatech.com>
	<1298726158.2423.24.camel@pierre-T500>
	<4D696E9E.9030808@candelatech.com>
	<1298798069.2407.9.camel@pierre-T500>
	<4D6A8141.2020200@candelatech.com>
Message-ID: <1298847297.2489.10.camel@pierre-T500>

Ben,

> Well, don't overestimate my own knowledge of xorp.  It's a huge project
> and there is lots I don't know myself, especially about the more interesting
> configuration options for various routing protocols, etc.

That answers actually scares me regarding all the stuff I have to deal
with in XORP in so little time :D. I'm just gonna die :D.

> I did a quick read on 'doku', and it seems it stores it's source
> in flat text files.  Maybe we could just periodically copy them to
> some directory in xorp.ct and commit them?  That way we have a
> backup that is easy for everyone to share.

Yeah, sure, why not.

> 
> That sounds nice...but unless someone else is posting patches, that
> means it's all on me. 

Oh no, when I meant "suggestions", it was about the documentation, not
about the sources ;-). I understand you've already got your hands full.

>  It will scale much better if other folks put
> some effort towards the latex.  For that matter, it doesn't have to
> be an official patch against the latex...just an email posting with
> corrected text and I'll figure out how to get it in latex if that's
> what it takes.

The biggest drawback (and advantage, according to the circumstances) of
LaTeX is that every time you modify the source files, you have to
recompile them to see the results. I'm not sure that's a burden that we
want to assume in order to readily discuss, correct, and improve
specific parts of the documentation ?

> 
> Thanks.  Your wiki is very nicely done.  I don't necessarily want to host
> it, but I would like to have the backup files within my control.  Then,
> if your project ever does cease operations, I could simply install doku
> and bring the wiki back online. That's basically what I had to do with xorp
> (forked it to xorp.ct and hosted it on my own site), so I'm a bit touchy
> about these things :)

That's exactly why I suggested to host it somewhere else as fast as
possible to ease that worry: our European project is supposed to be
terminated by September 2011... Our wiki will clearly be staying there
for a couple of more months/years, but after that date, I can't assume
anything. Nevertheless I won't let it be taken down unless I'm sure
someone else has got the backup running up.

Regards,

Pierre.



From greearb at candelatech.com  Sun Feb 27 21:46:12 2011
From: greearb at candelatech.com (Ben Greear)
Date: Sun, 27 Feb 2011 21:46:12 -0800
Subject: [Xorp-users] Xorp documentation
In-Reply-To: <1298847297.2489.10.camel@pierre-T500>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>	
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>	
	<4D59AF8A.4040502@candelatech.com>	
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>	
	<4D59B4B7.7060603@candelatech.com>	
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>	
	<4D5AD437.9000607@candelatech.com>	
	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>	
	<4D5ADA52.8000108@candelatech.com>	
	<65A6944974518C4B9C0E818727B559E9397F8692@mecexchange2007.meccorp.mec.edu>	
	<AANLkTikyRJcbKg1V44ggwq2gAjfPhpoks9o8cVraMQM8@mail.gmail.com>	
	<1298580928.2186.5.camel@pierre-T500>	
	<AANLkTi=bvtGzts5TUui9o35ggiwkZtb9x+59d6pLsEok@mail.gmail.!
	com>	 <4D66FD1C.8030602@candelatech.com>
	<1298726158.2423.24.camel@pierre-T500>	
	<4D696E9E.9030808@candelatech.com>
	<1298798069.2407.9.camel@pierre-T500>	
	<4D6A8141.2020200@candelatech.com>
	<1298847297.2489.10.camel@pierre-T500>
Message-ID: <4D6B36A4.9000902@candelatech.com>

On 02/27/2011 02:54 PM, Pierre Lepropre wrote:
> Ben,
>
>> Well, don't overestimate my own knowledge of xorp.  It's a huge project
>> and there is lots I don't know myself, especially about the more interesting
>> configuration options for various routing protocols, etc.
>
> That answers actually scares me regarding all the stuff I have to deal
> with in XORP in so little time :D. I'm just gonna die :D.

Turns out, you don't need to know it all to make some progress :)

>> I did a quick read on 'doku', and it seems it stores it's source
>> in flat text files.  Maybe we could just periodically copy them to
>> some directory in xorp.ct and commit them?  That way we have a
>> backup that is easy for everyone to share.
>
> Yeah, sure, why not.

Ok.  Please make sure you have permission and assuming you do,
please put the files up somewhere that I can get them, and I'll
put them into xorp.ct.

We can update the files manually for now, and if the files are
ever being changed quite often, we can set up some automated process
to commit and push changes.

>> That sounds nice...but unless someone else is posting patches, that
>> means it's all on me.
>
> Oh no, when I meant "suggestions", it was about the documentation, not
> about the sources ;-). I understand you've already got your hands full.
>
>>   It will scale much better if other folks put
>> some effort towards the latex.  For that matter, it doesn't have to
>> be an official patch against the latex...just an email posting with
>> corrected text and I'll figure out how to get it in latex if that's
>> what it takes.
>
> The biggest drawback (and advantage, according to the circumstances) of
> LaTeX is that every time you modify the source files, you have to
> recompile them to see the results. I'm not sure that's a burden that we
> want to assume in order to readily discuss, correct, and improve
> specific parts of the documentation ?

That's a good point.  We could periodically sweep info from the wiki
into the latex, but that still requires that someone do the work.
I like the printability (and conversion to pdf) that tex files give,
so it would take a lot of really good wiki docs before I'd consider
making the wiki the primary documentation source.

Also, once you install the tools, I think it's pretty quick to compile
the documentation.  Been a while since I tried it though...

>> Thanks.  Your wiki is very nicely done.  I don't necessarily want to host
>> it, but I would like to have the backup files within my control.  Then,
>> if your project ever does cease operations, I could simply install doku
>> and bring the wiki back online. That's basically what I had to do with xorp
>> (forked it to xorp.ct and hosted it on my own site), so I'm a bit touchy
>> about these things :)
>
> That's exactly why I suggested to host it somewhere else as fast as
> possible to ease that worry: our European project is supposed to be
> terminated by September 2011... Our wiki will clearly be staying there
> for a couple of more months/years, but after that date, I can't assume
> anything. Nevertheless I won't let it be taken down unless I'm sure
> someone else has got the backup running up.

I can certainly host it on our servers if the old ones go away.

Thanks,
Ben


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


From pierre.lepropre at student.ulg.ac.be  Sun Feb 27 23:51:21 2011
From: pierre.lepropre at student.ulg.ac.be (Pierre Lepropre)
Date: Mon, 28 Feb 2011 08:51:21 +0100
Subject: [Xorp-users] Xorp documentation
Message-ID: <5cay4xdpmfmnovl8794dljnt.1298879481585@email.android.com>

Ben,

I'm wondering if there isn't a possibility to export the wiki to latex directly. I'm gonna look into that and keep you updated.

Regards.

Sorry for my brevity, this mail was sent from my smartphone. Veuillez excuser ma bri?vet? : ce courrier a ?t? envoy? depuis mon smartphone.

Ben Greear <greearb at candelatech.com> a ?crit?:

>On 02/27/2011 02:54 PM, Pierre Lepropre wrote:
>> Ben,
>>
>>> Well, don't overestimate my own knowledge of xorp.  It's a huge project
>>> and there is lots I don't know myself, especially about the more interesting
>>> configuration options for various routing protocols, etc.
>>
>> That answers actually scares me regarding all the stuff I have to deal
>> with in XORP in so little time :D. I'm just gonna die :D.
>
>Turns out, you don't need to know it all to make some progress :)
>
>>> I did a quick read on 'doku', and it seems it stores it's source
>>> in flat text files.  Maybe we could just periodically copy them to
>>> some directory in xorp.ct and commit them?  That way we have a
>>> backup that is easy for everyone to share.
>>
>> Yeah, sure, why not.
>
>Ok.  Please make sure you have permission and assuming you do,
>please put the files up somewhere that I can get them, and I'll
>put them into xorp.ct.
>
>We can update the files manually for now, and if the files are
>ever being changed quite often, we can set up some automated process
>to commit and push changes.
>
>>> That sounds nice...but unless someone else is posting patches, that
>>> means it's all on me.
>>
>> Oh no, when I meant "suggestions", it was about the documentation, not
>> about the sources ;-). I understand you've already got your hands full.
>>
>>>   It will scale much better if other folks put
>>> some effort towards the latex.  For that matter, it doesn't have to
>>> be an official patch against the latex...just an email posting with
>>> corrected text and I'll figure out how to get it in latex if that's
>>> what it takes.
>>
>> The biggest drawback (and advantage, according to the circumstances) of
>> LaTeX is that every time you modify the source files, you have to
>> recompile them to see the results. I'm not sure that's a burden that we
>> want to assume in order to readily discuss, correct, and improve
>> specific parts of the documentation ?
>
>That's a good point.  We could periodically sweep info from the wiki
>into the latex, but that still requires that someone do the work.
>I like the printability (and conversion to pdf) that tex files give,
>so it would take a lot of really good wiki docs before I'd consider
>making the wiki the primary documentation source.
>
>Also, once you install the tools, I think it's pretty quick to compile
>the documentation.  Been a while since I tried it though...
>
>>> Thanks.  Your wiki is very nicely done.  I don't necessarily want to host
>>> it, but I would like to have the backup files within my control.  Then,
>>> if your project ever does cease operations, I could simply install doku
>>> and bring the wiki back online. That's basically what I had to do with xorp
>>> (forked it to xorp.ct and hosted it on my own site), so I'm a bit touchy
>>> about these things :)
>>
>> That's exactly why I suggested to host it somewhere else as fast as
>> possible to ease that worry: our European project is supposed to be
>> terminated by September 2011... Our wiki will clearly be staying there
>> for a couple of more months/years, but after that date, I can't assume
>> anything. Nevertheless I won't let it be taken down unless I'm sure
>> someone else has got the backup running up.
>
>I can certainly host it on our servers if the old ones go away.
>
>Thanks,
>Ben
>
>
>-- 
>Ben Greear <greearb at candelatech.com>
>Candela Technologies Inc  http://www.candelatech.com


From greearb at candelatech.com  Mon Feb 28 05:40:55 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 28 Feb 2011 05:40:55 -0800
Subject: [Xorp-users] Xorp documentation
In-Reply-To: <5cay4xdpmfmnovl8794dljnt.1298879481585@email.android.com>
References: <5cay4xdpmfmnovl8794dljnt.1298879481585@email.android.com>
Message-ID: <4D6BA5E7.6050706@candelatech.com>

On 02/27/2011 11:51 PM, Pierre Lepropre wrote:
> Ben,
>
> I'm wondering if there isn't a possibility to export the wiki to latex directly. I'm gonna look into that and keep you updated.
>
> Regards.

You can certainly write html so that it prints nicely, and it's easy to print
to pdf.

That is good enough for me..but user-guides are nice if they can be read somewhat like
a book ( a big linear document), and web pages are often more useful if they are shorter
with links to appropriate pages.

Someone could convert the latex to html (and have some scripts to convert the
individual sections into a complete document, using <!-- START_CONTENT --> or
similar tags.  I'm not sure we could edit the result in a wiki, but probably
more folks understand html and latex, so maybe it would still be a win.

About the only thing that is really difficult to do in html is to add page
headers/footers.  And it might take some css to get the printing to look
nicely...

Thanks,
Ben

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


From greearb at candelatech.com  Mon Feb 28 07:59:43 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 28 Feb 2011 07:59:43 -0800
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D5ADA52.8000108@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>	<4D55849A.3010601@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>	<4D558CA4.4090301@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>	<4D594C19.4010504@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>	<4D598F5B.1000405@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>,
	<4D59AA1E.7000608@candelatech.com>	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>,
	<4D59AF8A.4040502@candelatech.com>	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>	<4D59B4B7.7060603@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>	<4D5AD437.9000607@candelatech.com>	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>
	<4D5ADA52.8000108@candelatech.com>
Message-ID: <4D6BC66F.6090505@candelatech.com>

On 02/15/2011 11:56 AM, Ben Greear wrote:
> On 02/15/2011 11:57 AM, Joe Coco wrote:
>> Hi Ben,
>>
>>> I think I fixed one problem with the EEXIST already...are you using the latest xorp.ct git tree from github?
>>> This is something you'd need to clone with git, not just download a canned snapshot.
>>
>> I'm actually merging your changes with mine now, and I do see you made a fix for that.  Doh!
>>
>> I wasn't really sure how far you got fixing up the vlan code based on your comments last night, so I continued in the direction I was going in until this afternoon. I'm merging your changes now, especially now that I know a bit more about the code and what you changed.
>>
>> So in GIT, where are we with your changes functionality wise? Did you get it to the point where you can add and delete dev.vid vlan's and it set the appropriate IP address?
>
> Yes, but the interface will not be admin up, and all sorts of code will not
> actually function properly.
>
> 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...

Just FYI, I was feeling motivated and started working on this.  I still
got a bit to go, but so far so good.  I hope to post some useful patches
within a few days.

Thanks,
Ben

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


From B32946 at freescale.com  Mon Feb 28 08:10:19 2011
From: B32946 at freescale.com (Vunnava Kesava Srinivas-B32946)
Date: Mon, 28 Feb 2011 16:10:19 +0000
Subject: [Xorp-users] Help Needed in PIM-Join Messages !!
Message-ID: <9D8289DE2B23FA4EBC165B4CFB3718660B3586@039-SN1MPN1-004.039d.mgd.msft.net>

Hi Guys,
I have a requirement to bring up Multicast Routing [IPv4 Network] with pimsm4. The Topology that I am trying to configure is ;
"Multicast Sender <--------->RP<------------->DSR<-------------->Multicast Listener". I have connected everything Point- Point. So., No need to worry about routes.

I am seeing that Listener is sending IGMPv3 Join reports to the DSR. But even though pim-sm is running on DSR; it is NOT sending PIM-Join Messages to the RP. I have configured staticrp in the DSR & and the connectivity between the RP & DSP is Fine. I have attached the configuration file of both the RP & DSR. Please let me know what configuration am I missing !!!

Few Doubts:
1] Also another question is., If I am enabling IGMP on both the interfaces of DSR & RP will that matter & effect PIM Routing ??
2] How Plumbing effects Multicast Routing.


-Thanks in Advance,
VKS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110228/865c4be2/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DSR.rtf
Type: application/msword
Size: 1590 bytes
Desc: DSR.rtf
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110228/865c4be2/attachment-0002.dot 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RP.rtf
Type: application/msword
Size: 1740 bytes
Desc: RP.rtf
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110228/865c4be2/attachment-0003.dot 

From william at losrios.edu  Mon Feb 28 08:23:21 2011
From: william at losrios.edu (Williams, Mark)
Date: Mon, 28 Feb 2011 16:23:21 +0000
Subject: [Xorp-users] Help Needed in PIM-Join Messages !!
In-Reply-To: <9D8289DE2B23FA4EBC165B4CFB3718660B3586@039-SN1MPN1-004.039d.mgd.msft.net>
References: <9D8289DE2B23FA4EBC165B4CFB3718660B3586@039-SN1MPN1-004.039d.mgd.msft.net>
Message-ID: <C025046A77B3034399C773D87A765D2E1B13BDCC@LRCCD-MBX01.LRCCD.ad.losrios.edu>

You need to uncomment the section on fib2mrib in the configuration on your DSR. PIM routers need to use the unicast forwarding table to be able to find the reverse path back to the RP.

If you configure the RP router as a BSR and candidate RP, then let the DSR learn the RP information using bootstrap; don't configure it statically.

-Mark Williams

From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On Behalf Of Vunnava Kesava Srinivas-B32946
Sent: Monday, February 28, 2011 08:10
To: xorp-users at xorp.org
Subject: [Xorp-users] Help Needed in PIM-Join Messages !!

Hi Guys,
I have a requirement to bring up Multicast Routing [IPv4 Network] with pimsm4. The Topology that I am trying to configure is ;
"Multicast Sender <--------->RP<------------->DSR<-------------->Multicast Listener". I have connected everything Point- Point. So., No need to worry about routes.

I am seeing that Listener is sending IGMPv3 Join reports to the DSR. But even though pim-sm is running on DSR; it is NOT sending PIM-Join Messages to the RP. I have configured staticrp in the DSR & and the connectivity between the RP & DSP is Fine. I have attached the configuration file of both the RP & DSR. Please let me know what configuration am I missing !!!

Few Doubts:
1] Also another question is., If I am enabling IGMP on both the interfaces of DSR & RP will that matter & effect PIM Routing ??
2] How Plumbing effects Multicast Routing.


-Thanks in Advance,
VKS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110228/8281b82d/attachment.html 

From jcoco at meccorp.mec.edu  Mon Feb 28 08:34:20 2011
From: jcoco at meccorp.mec.edu (Joe Coco)
Date: Mon, 28 Feb 2011 11:34:20 -0500
Subject: [Xorp-users] VLAN Interfaces
In-Reply-To: <4D6BC66F.6090505@candelatech.com>
References: <20110208202405.C3745B882E9@cheetah.cs.fiu.edu>
	<4D55849A.3010601@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F844F@mecexchange2007.meccorp.mec.edu>
	<4D558CA4.4090301@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84C7@mecexchange2007.meccorp.mec.edu>
	<4D594C19.4010504@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F84EC@mecexchange2007.meccorp.mec.edu>
	<4D598F5B.1000405@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F858B@mecexchange2007.meccorp.mec.edu>,
	<4D59AA1E.7000608@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C23@mecexchange2007.meccorp.mec.edu>,
	<4D59AF8A.4040502@candelatech.com>
	<65A6944974518C4B9C0E818727B559E939357C24@mecexchange2007.meccorp.mec.edu>
	<4D59B4B7.7060603@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F8684@mecexchange2007.meccorp.mec.edu>
	<4D5AD437.9000607@candelatech.com>
	<65A6944974518C4B9C0E818727B559E9397F868A@mecexchange2007.meccorp.mec.edu>
	<4D5ADA52.8000108@candelatech.com>,<4D6BC66F.6090505@candelatech.com>
Message-ID: <65A6944974518C4B9C0E818727B559E939357C31@mecexchange2007.meccorp.mec.edu>

> Just FYI, I was feeling motivated and started working on this.  I still
> got a bit to go, but so far so good.  I hope to post some useful patches
> within a few days.



Hi Ben,

Sounds great. Looking forward to seeing your patches!

-- Joe



From peirce at maine.edu  Sun Feb 27 11:30:35 2011
From: peirce at maine.edu (Garry Peirce)
Date: Sun, 27 Feb 2011 14:30:35 -0500
Subject: [Xorp-users] mfea4 issues
In-Reply-To: <C98D46FB.15F0E%nschmidt@mediamath.com>
References: <AANLkTi=uYwfN5FhC5ddyHqXgU01MZNo-6_d34xic6N5M@mail.gmail.com>
	<C98D46FB.15F0E%nschmidt@mediamath.com>
Message-ID: <000401cbd6b4$ce5e3950$6b1aabf0$@maine.edu>

The config appears ok to me, although a bit out of 'normal' order I usually
see - is this a copy of your saved config.boot?

 

Within the MFEA section, why is this vif disabled?  It wouldn't seem
directly related, but given the odd behavior, I wonder why.

    interface eth0.512 {
        vif eth0.512 {
        disable: true
        }

 

Can we see the output of ifconfig too?

 

 

Description: cid:image001.jpg at 01CBD684.9CCC4150

 

From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org] On
Behalf Of Nicholas Schmidt
Sent: Friday, February 25, 2011 11:46 AM
To: Ray Soucy
Cc: xorp-users at xorp.org
Subject: Re: [Xorp-users] mfea4 issues

 

I have provided the configuration and error in my original email. Here it is
again for those who have missed it. I have read through and configured per
the Getting Started documentation.

-Nick

Log:

[ 2011/02/24 16:26:54  INFO xorp_rtrmgr:3981 RTRMGR +101 module_manager.cc
execute ] Executing module: firewall (fea/xorp_fea)
[ 2011/02/24 16:26:58  INFO xorp_rtrmgr:3981 RTRMGR +101 module_manager.cc
execute ] Executing module: fea (fea/xorp_fea)
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +101 module_manager.cc
execute ] Executing module: mfea4 (fea/xorp_fea)
[ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] Interface added: Vif[eth0.33]
pif_index: 4 vif_index: 0 addr: 74.121.138.180 subnet: 74.121.138.0/24
broadcast: 74.121.138.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
UNDERLYING_VIF_UP MTU: 1500
[ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] Interface added: Vif[eth0.512]
pif_index: 5 vif_index: 1 addr: 10.3.3.1 subnet: 10.3.3.0/24 broadcast:
10.3.3.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST UNDERLYING_VIF_UP MTU:
1500
[ 2011/02/24 16:27:05  ERROR xorp_fea:3982 MFEA +709 mfea_mrouter.cc
start_mrt ] setsockopt(MRT_INIT, 1) failed: Address already in use
[ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] MFEA started
[ 2011/02/24 16:27:05 INFO xorp_fea MFEA ] Interface enabled Vif[eth0.33]
pif_index: 4 vif_index: 0 addr: 74.121.138.180 subnet: 74.121.138.0/24
broadcast: 74.121.138.255 peer: 0.0.0.0 Flags: MULTICAST BROADCAST
UNDERLYING_VIF_UP MTU: 1500 DOWN IPv4 ENABLED
[ 2011/02/24 16:27:05  ERROR xorp_fea:3982 MFEA +1113 mfea_mrouter.cc
add_multicast_vif ] setsockopt(MRT_ADD_VIF, vif eth0.33) failed: Address
already in use
[ 2011/02/24 16:27:05  ERROR xorp_fea:3982 MFEA +1191 mfea_node.cc start_vif
] Cannot start vif eth0.33: cannot add the multicast vif to the kernel
[ 2011/02/24 16:27:05 WARNING xorp_fea XrlMfeaTarget ] Handling method for
mfea/0.1/start_vif failed: XrlCmdError 102 Command failed Cannot start vif
eth0.33: cannot add the multicast vif to the kernel
[ 2011/02/24 16:27:05  ERROR xorp_rtrmgr:3981 RTRMGR +691
master_conf_tree.cc commit_pass2_done ] Commit failed: 102 Command failed
Cannot start vif eth0.33: cannot add the multicast vif to the kernel
[ 2011/02/24 16:27:05  ERROR xorp_rtrmgr:3981 RTRMGR +261
master_conf_tree.cc config_done ] Configuration failed: 102 Command failed
Cannot start vif eth0.33: cannot add the multicast vif to the kernel
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +2233 task.cc run_task ]
No more tasks to run
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc
terminate ] Terminating module: fea
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc
terminate ] Terminating module: firewall
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc
terminate ] Terminating module: interfaces
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +176 module_manager.cc
terminate ] Terminating module: mfea4
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +199 module_manager.cc
terminate ] Killing module: mfea4
[ 2011/02/24 16:27:05  ERROR xorp_rtrmgr:3981 RTRMGR +754 module_manager.cc
done_cb ] Command "/usr/local/xorp/fea/xorp_fea": terminated with signal 15.
[ 2011/02/24 16:27:05  INFO xorp_rtrmgr:3981 RTRMGR +287 module_manager.cc
module_exited ] Module killed during shutdown: mfea4

Configuration:

interfaces {
    restore-original-config-on-shutdown: false
    interface eth0.33 {
    description: "data interface"
    disable: false
    /* default-system-config */
    vif eth0.33 {
        disable: false
        address 2.2.2.2 {
        prefix-length: 24
        broadcast: 2.2.2.255
        disable: false
        }
    }
    }
    interface eth0.512 {
    description: "data interface"
    disable: false
    /* default-system-config */
    vif eth0.512 {
        disable: false
        address 1.1.1.1 {
        prefix-length: 24
        broadcast: 1.1.1.255
        disable: false
        }
    }
    }
}

fea {
    unicast-forwarding4 {
        disable: false
    }
}
protocols {
    static {
    route 1.1.0.0/22 {
        next-hop: 10.3.3.2
        metric: 1
    }
    route 1.1.3.0/24 {
        next-hop: 74.121.138.1
        metric: 1
    }
   }
}

plumbing {
    mfea4 {
    disable: false
    interface eth0.33 {
        vif eth0.33 {
        disable: false
        }
    }
    interface eth0.512 {
        vif eth0.512 {
        disable: true
        }
    }
    interface register_vif {
        vif register_vif {
        /* Note: this vif should be always enabled */
        disable: false
        }
    }
    traceoptions {
        flag all {
        disable: false
        }
    }
    }
}


protocols {
    pimsm4 {
    disable: false
    interface eth0.33 {
        vif eth0.33 {
        disable: false
        /* enable-ip-router-alert-option-check: false */
        /* dr-priority: 1 */
        /* hello-period: 30 */
        /* hello-triggered-delay: 5 */
        }
    }
    interface eth0.512 {
        vif eth0.512 {
        disable: false
        /* enable-ip-router-alert-option-check: false */
        /* dr-priority: 1 */
        /* hello-period: 30 */
        /* hello-triggered-delay: 5 */
        }
    }
    interface register_vif {
        vif register_vif {
        /* Note: this vif should be always enabled */
        disable: false
        }
    }

    static-rps {
        rp 6.6.6.6 {
        group-prefix 224.0.0.0/4 {
            /* rp-priority: 192 */
            /* hash-mask-len: 30 */
        }
        }
    }

    switch-to-spt-threshold {
        /* approx. 1K bytes/s (10Kbps) threshold */
        disable: false
        interval: 100
        bytes: 102400
    }

    traceoptions {
        flag all {
        disable: false
        }
    }
   }
}
protocols {
    igmp {
    disable: false
    interface eth0.33 {
        vif eth0.33 {
        disable: false
        /* version: 2 */
        /* enable-ip-router-alert-option-check: false */
        /* query-interval: 125 */
        /* query-last-member-interval: 1 */
        /* query-response-interval: 10 */
        /* robust-count: 2 */
        }
    }
    interface eth0.512 {
        vif eth0.512 {
        disable: false
        /* version: 2 */
        /* enable-ip-router-alert-option-check: false */
        /* query-interval: 125 */
        /* query-last-member-interval: 1 */
        /* query-response-interval: 10 */
        /* robust-count: 2 */
        }
    }
    traceoptions {
        flag all {
        disable: false
        }
    }
    }
}





On 2/25/11 11:41 AM, "Ray Soucy" <rps at maine.edu> wrote:

Hi Nicholas,

We have a pretty large XORP deployment for multicast.  In our
experience 90% of problems people run into are configuration issues.

Can you provide us with your XORP configuration?  Also be sure to
check that you don't have iptables blocking the traffic.

On Fri, Feb 25, 2011 at 11:32 AM, Nicholas Schmidt
<nschmidt at mediamath.com> wrote:
> This is a clean installation of Debian with no routing processes in the
> background running Kernel 2.6.26-2-amd64 and xorp version 1.6
>
> -Nick
>
>
> On 2/24/11 7:23 PM, "Ben Greear" <greearb at candelatech.com> wrote:
>
> On 02/24/2011 01:30 PM, Nicholas Schmidt wrote:
>> Greetings list,
>> I am attempting to run xorp for the first time to satisfy some multicast
>> routing needs that is not currently supported by our hardware vendor. I
have
>> attempted
>> to write the simplist possible configuration for my needs based on the
>> guides provided by I receive an MFEA4 error when attempting to launch the
>> application.
>> Any help would be appreciated.
>
> Are you running any other routing daemons, or maybe some xorp processes
> running in the background?
>
> What xorp version?
>
> What kernel version?
>
> Thanks,
> Ben
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>
>



--
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110227/69c01132/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 11359 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110227/69c01132/attachment-0001.jpe 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Garry Peirce.vcf
Type: application/octet-stream
Size: 4373 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20110227/69c01132/attachment-0001.obj 

From greearb at candelatech.com  Mon Feb 28 22:08:52 2011
From: greearb at candelatech.com (Ben Greear)
Date: Mon, 28 Feb 2011 22:08:52 -0800
Subject: [Xorp-users] RFC:  New VLAN api for xorp.ct
Message-ID: <4D6C8D74.9090602@candelatech.com>

Here is a patch I cooked up to deal with automatically
creating/deleting VLANs, while treating them as real
interfaces.

This is totally un-tested (it does compile on Linux, at least).

Comments welcome.  I hope to test it in the next few days.

http://www.candelatech.com/~greearb/0001-vlans-Treat-vlans-as-primary-interfaces.patch

Thanks,
Ben

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