[Xorp-users] XORP 1.6 Questions and Comments (with examples)
Garry Peirce
peirce at maine.edu
Sun Jul 11 09:46:25 PDT 2010
1 - As both paths are known via RIP you'll only see the best RIP route.
The command in XORP 1.6 (from what I've seen) reports the rip table after
the RIP filter bank. Given unequal metrics the lower one wins. Given equal
metrics the first known path wins.
You'd never see equal paths inserted into the kernel as XORP (to my
knowledge) doesn't support ECMP.
2 - we must define vlan interfaces individual and not as vifs as mcast
configuration will fail (via experience).
3 - register-vif requires the use of another interface's address and
therefore (in 1.6) must be defined first.
> -----Original Message-----
> From: xorp-users-bounces at xorp.org [mailto:xorp-users-bounces at xorp.org]
> On Behalf Of Ray Soucy
> Sent: Friday, July 09, 2010 2:32 PM
> To: xorp-users
> Subject: [Xorp-users] XORP 1.6 Questions and Comments (with examples)
>
> Wanted to give a little feedback and pick your brain about XORP as
> we're starting to try it in production for K12 as a cost-savings
> measure.
>
> I apologize in advance for how lengthy this turned out to be.
>
> Issue 1:
>
> I'm using RIP over point-to-point links to provide routing for XORP
> 1.6 on Linux
>
> One thing I notice is that in a setup with two links (for a backup
> path) XORP will only pass the winning routes to the kernel routing
> table. This is OK, but it does make troubleshooting routing issues a
> bit difficult. One would expect that within XORP you could view
> routes available from both paths but that isn't the case either.
>
> Example:
> Link A is 10.0.0.2/31
> Link B is 10.0.0.4/31
>
> XORP box has Link A and Link B coming in as 802.1Q tagged VLAN's 2 and
> 3.
> Link A has a metric of 1 and Link B has a metric of 2.
>
> XORP config:
> ----8<----
> protocols {
> fib2mrib {
> disable: false
> }
> rip {
> interface eth0 {
> vif "eth0.2" {
> address 10.0.0.3 {
> metric: 1
> horizon: "split-horizon-poison-reverse"
> disable: false
> passive: false
> accept-non-rip-requests: true
> 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
> }
> }
> vif "eth0.3" {
> address 10.0.0.5 {
> metric: 2
> horizon: "split-horizon-poison-reverse"
> disable: false
> passive: false
> accept-non-rip-requests: true
> 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
> }
> }
> }
> }
> }
> fea {
> unicast-forwarding4 {
> disable: false
> forwarding-entries {
> retain-on-startup: true
> retain-on-shutdown: true
> }
> }
> }
> interfaces {
> restore-original-config-on-shutdown: true
> 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 {
> }
> }
> interface "eth0.2" {
> description: "Link A"
> disable: false
> discard: false
> unreachable: false
> management: false
> vif "eth0.2" {
> disable: false
> address 10.0.0.3 {
> prefix-length: 31
> disable: false
> }
> }
> }
> interface "eth0.3" {
> description: "Link B"
> disable: false
> discard: false
> unreachable: false
> management: false
> vif "eth0.3" {
> disable: false
> address 10.0.0.5 {
> prefix-length: 31
> disable: false
> }
> }
> }
> }
> ----8<----
>
> One would expect that either:
>
> 1. Routes from both paths make it into the kernel routing table with
> the appropriate metric and the kernel decides which one to use.
>
> or
>
> 2. XORP displays routes for both paths internally but only sends the
> winning route to the kernel.
>
> What I would expect to see would be:
>
> 10.0.0.2 0.0.0.0 255.255.255.254 U 0 0 0
> eth0.2
> 10.0.0.4 0.0.0.0 255.255.255.254 U 0 0 0
> eth0.3
> 192.168.0.0 0.0.0.0 255.255.254.0 U 0 0 0
> eth1
> 0.0.0.0 10.0.0.2 0.0.0.0 UG 1 0 0
> eth0.2
> 0.0.0.0 10.0.0.4 0.0.0.0 UG 2 0 0
> eth0.3
>
> But in practice the route advertised from Link B doesn't show up in
> the kernel unless the route from Link A is absent.
>
> If I check the routing table in XORP it doesn't show any candidate
> routes either.
>
> Was this the intended behavior of XORP? Not being able to see
> candidate routes on a device can make troubleshooting a bit
> challenging.
>
> Issue 2:
>
> It seems that the only way I can get XORP to talk to 802.1Q interfaces
> consistantly is to define them as physical interfaces not as VIF's as
> the manual implies.
>
> e.g.
>
> ----8<----
> interface eth0 {
> description: "WAN"
> disable: false
> discard: false
> unreachable: false
> management: false
> vif eth0 {
> disable: true
> }
> vif "eth0.2" {
> disable: false
> vlan {
> vlan-id: 2
> }
> address 10.0.0.3 {
> prefix-length: 31
> disable: false
> }
> }
> vif "eth0.3" {
> disable: false
> vlan {
> vlan-id: 3
> }
> address 10.0.0.5 {
> prefix-length: 31
> disable: false
> }
> }
> }
> ----8<----
>
> Will seem to work for RIP but fail completely when MFEA is started.
> In addition if the 802.1Q interface already exists then XORP throws
> an error. If it doesn't exist XORP fails to create it and throws
> an error.
>
> Instead we found that the only thing that works is to manually create
> the 802.1Q interfaces and then define them as physical interfaces in
> XORP.
>
> e.g.
>
> ----8<----
> interface "eth0.2" {
> description: "Link A"
> disable: false
> discard: false
> unreachable: false
> management: false
> vif "eth0.2" {
> disable: false
> address 10.0.0.3 {
> prefix-length: 31
> disable: false
> }
> }
> }
> interface "eth0.3" {
> description: "Link B"
> disable: false
> discard: false
> unreachable: false
> management: false
> vif "eth0.3" {
> disable: false
> address 10.0.0.5 {
> prefix-length: 31
> disable: false
> }
> }
> }
> ----8<----
>
> Is this the correct way to configure XORP or is it just a work-around
> for a bug in 802.1Q implimentation?
>
> Issue 3:
>
> When configuring XORP for multicast under the MFEA the "register_vif"
> interface is required.
>
> We ran into a pretty confusing issue where if the "register_vif"
> interface is defined first XORP throws a fit and fails to start. If
> it's defined 2nd, last, or anyplace in between it works fine.
>
> e.g.
>
> ----8<----
> plumbing {
> mfea4 {
> disable: false
> interface "register_vif" {
> vif "register_vif" {
> disable: false
> }
> }
> interface eth1 {
> vif eth1 {
> disable: false
> }
> }
> }
> }
> ----8<----
>
> This will fail to start.
>
> ----8<----
> plumbing {
> mfea4 {
> disable: false
> interface eth1 {
> vif eth1 {
> disable: false
> }
> }
> interface "register_vif" {
> vif "register_vif" {
> disable: false
> }
> }
> }
> }
> ----8<----
>
> This one will work fine. Took a while to figure that one out...
>
> Also notice that for PIM-SM to work the IP addresses need to be
> explicitly defined in XORP. If we try default-system-config it fails.
>
> Recap:
>
> So while the manual implies that you should configure 802.1Q
> interfaces as VIF's that doesn't seem to work. The only way we've
> found to get things working is to manually create the interfaces then
> start XORP with them defined as physical interfaces.
>
> Is this correct or are we just doing it wrong?
>
> Ordering of "register_vif" interface being relavant is a little
> annoying.
>
> Not seeing any good way to see candidate routes in XORP.
>
> --
> Ray Soucy
>
> Epic Communications Specialist
>
> Phone: +1 (207) 561-3526
>
> Networkmaine, a Unit of the University of Maine System
> http://www.networkmaine.net/
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
More information about the Xorp-users
mailing list