[Xorp-users] XORP 1.6 Questions and Comments (with examples)

Ray Soucy rps at maine.edu
Fri Jul 9 11:32:27 PDT 2010


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/



More information about the Xorp-users mailing list