[Xorp-users] Fwd: from and to blocks of policy terms

[Andreas Voellmy]

A while back I asked a few questions about the semantics of BGP
policies in Xorp. I now have a 3 computer Xorp setup so I can actually
try these policies. I've just gotten started with my experiments, but
already I've found cases which don't seem to match either the xorp
manual or what I've heard on this list. It's also possible that I've
misunderstood something. I'd really appreciate some help understanding
these policies.

I have a setup with three computers, called A, B, and C, running xorp
bgp sessions between each pair (AB,AC,BC). C redistributes a static
route to A, but not to B. There are no other routes being advertised
or redistributed in the system.

When I configure A with this import policy "from {neighbor: [C's
address]} then {reject}", I would expect that A will not enter any
route learned from C into its bgp table. However, when I run a "show
bgp routes" command , the route from C shows up. It is marked as valid
("*") but not as being the best (">"). The manual says that a route is
valid when the nexthop is reachable and when the route is not filtered
by inbound filters. According to this, I'd expect the route to be
considered invalid and for no "*" to show up. Otherwise, if it is
valid, why is it not the best route (since it is the only route in A's
table). I have tracing on in my import filter and the trace output
shows the result of the term, filter & whole filter to be "reject".
I've pasted my actual configurations below in case that is useful to
anyone.

As a second experiment I configured A with the export policy "from
{protocol: "bgp"; neighbor: [C's address]} then {reject}". I would
expect that this would have no effect on import policy, but would
prevent any routes learned from C to be advertised to any peers. The
behavior of the router is ALMOST consistent with this, but is actually
quite odd. When A starts up, it sends a route advertisement for the
route learned from C to B. B momentarily installs the route. Then A
sends B an update message to withdraw the route, so B removes it from
its table. I find this really odd. Why does A send the route to B at
all?

Thanks for your help. The configurations are pasted below.

--Andreas


/*
This is Computer A

Computer A is 192.168.0.1
Computer B is 192.168.0.3
Computer C is 192.168.0.2
*/


interfaces {
    restore-original-config-on-shutdown: false
    interface "eth0" {
    description: "data interface"
    disable: false
    vif "eth0" {
        disable: false
        address 192.168.0.1 {
        prefix-length: 16
        broadcast: 192.168.255.255
        disable: false
        }
    }
    }
}

fea {
    unicast-forwarding4 {
    disable: false
    forwarding-entries {
        retain-on-startup: false
        retain-on-shutdown:    false
    }
    }
}

protocols {
    bgp {
        bgp-id: 192.168.0.1
        local-as: 45678

        peer 192.168.0.2 {
            local-ip: 192.168.0.1
            as: 34567
            next-hop: 192.168.0.1
        }

        peer 192.168.0.3 {
            local-ip: 192.168.0.1
            as: 23456
            next-hop: 192.168.0.1
        }


        /* import: "imppol" */
        export: "exppol"

    }
}

policy {

    policy-statement imppol {
        term impterm {
            from {
                neighbor: 192.168.0.2
            }
            then {
                trace: 4
                reject
            }
        }
    }

    policy-statement exppol {
        term expterm {
            from {
                protocol: "bgp"
                neighbor: 192.168.0.2
            }
            then {
                trace: 4
                reject
            }
        }
    }
}

/*

This is Computer C

Computer A is 192.168.0.1
Computer B is 192.168.0.3
Computer C is 192.168.0.2
*/

interfaces {
    restore-original-config-on-shutdown: false
    interface "eth0" {
	description: "data interface"
	disable: false
	vif "eth0" {
	    disable: false
	    address 192.168.0.2 {
		prefix-length: 16
		broadcast: 192.168.255.255
		disable: false
	    }
	}
    }
}

fea {
    unicast-forwarding4 {
	disable: false
	forwarding-entries {
	    retain-on-startup: false
	    retain-on-shutdown:	false
	}
    }
}

protocols {
	static {
		route 10.10.11.0/24 {
			next-hop: 192.168.0.2
		}
	}
}

protocols {
	bgp {
		bgp-id: 192.168.0.2
		local-as: 34567

		peer 192.168.0.1 {
			local-ip: 192.168.0.2
			as: 45678
			next-hop: 192.168.0.2
		}
		peer 192.168.0.3 {
			local-ip: 192.168.0.2
			as: 23456
			next-hop: 192.168.0.2
		}
		export: "exppol"
	}
}

policy {
	policy-statement exppol {
		term exppolterm1 {
			from {
				protocol: "static"
			}
			to {
				neighbor: 192.168.0.1
			}
			then {
				accept
			}
		}
		term exppolterm2 {
			from {
				protocol: "static"
			}
			then {
				reject
			}
		}
	}
}

/*

This is Computer B

Computer A is 192.168.0.1
Computer B is 192.168.0.3
Computer C is 192.168.0.2
*/

interfaces {
    restore-original-config-on-shutdown: false
    interface "eth0" {
	description: "data interface"
	disable: false
	vif "eth0" {
	    disable: false
	    address 192.168.0.3 {
		prefix-length: 16
		broadcast: 192.168.255.255
		disable: false
	    }
	}
    }
}

fea {
    unicast-forwarding4 {
	disable: false
	forwarding-entries {
	    retain-on-startup: false
	    retain-on-shutdown:	false
	}
    }
}

protocols {
	static {
		route 10.10.12.0/24 {
			next-hop: 192.168.0.3
		}
	}
}

protocols {
	bgp {
		bgp-id: 192.168.0.3
		local-as: 23456

		peer 192.168.0.1 {
			local-ip: 192.168.0.3
			as: 45678
			next-hop: 192.168.0.3
		}
		peer 192.168.0.2 {
			local-ip: 192.168.0.3
			as: 34567
			next-hop: 192.168.0.3
		}
		import: "imppol"
	}
}

policy {
	policy-statement imppol {
		term imppolterm {
			then {
				trace: 4
				accept
			}
		}
	}
}