OS10 route leaks not matching filter

Hello,

I see that the routes are showing up in the Voice VRF but the IP prefix list did not filter out the unwanted routes.

You can try to use the syntax example provided on page 1566 of the OS10 10.5.4 OS10 User Guide

https://dell.to/3RTeXnr

ip prefix-list name permit [A.B.C.D/x [ge | le]] prefix-len

@Dell -Charles R​  thanks. That is what I typed in. The "seq 10" was added by the switch. And the syntax seems to be correct to catch any route that falls in the /16; from page 1535: "For example, in 112.24.0.0/16, the first 16 bits of the address 112.24.0.0 match all addresses between 112.24.0.0
to 112.24.255.255." It's like the route map isn't actually filtering the export.

Hi, might be checking to verify each VRF is helpful. To confirm the routes in each VRF, you can use the command show ip route vrf <name>. To see the forwarding information base for each VRF, you can use the command show ip cef vrf <name>

I did show ip route; that's how I know it's not working as intended. show ip cef does not appear to be a Dell command.

Maybe this is a software issue. I didn't come across an article directly related to this. Let's see what our community will suggest.

Hello,

I had another observation is that the route-map usually has a match clause and a set clause.

In your case there is a match clause only.

route-map voice-export permit 10

       match ip address voice-export

For example on page 1045 of the same document, this is the syntax for the set clause:

set {ip | ipv6} vrf vrf-name next-hop next-hop-ipv4address

This next-hop-address is reachable through a different VRF instance in your case Voice VRF.

If the next-hop is reachable on the specified vrf VOICE instance, the packet will be redirected;

otherwise, the packet follows the regular routing flow.

Possibly in your case adding the SET clause can redirect only the Matched traffic.

I looked at set next-hop and all of the variations call for a next hop IP address and it needs to be more general; there is no single interface to direct the traffic to. I set a community string just to see if any set clause would work, but it didn't change the outcome.

The examples I've seen, such as on page 754 of the 10.5.4 User Guide, do not include a set clause. I can't make a protocol source, as in that example, work for this. 

I wonder if there is some disconnect between the prefix list and the route map. There is supposed to be a default deny but even a list with specific deny statements for the rest of the RFC1918 address space has no effect. It's like either the prefix list or calling it from the route map don't actually work.

Apt5,

You may want to consider calling into support, as it may require direct access and reviewing the logs to find the specific source of the leak and to correct it. 

I just deleted the route export and changed the route map to set the metric to 15. Then I ran "show ip bgp" and none of the routes have the metric changed by the route map. So none of the route maps I've tried seem to be working. That is apparently the problem; there is some hook or parameter missing to make the route maps work.

@DELL-Chris H​ We're not trying to find the source of a leak, we're trying to cause one; leaking routes from one VRF to another. I have asked our SE about it and I'm thinking of putting in a ticket also. Thanks.

Hello apt5,

One possibility is if you have not applied the route map to the correct interfaces and the BGP instance.

Here is example how to apply to BGP instance

OS10(config)# router bgp 100

OS10(conf-router-bgp-102)# neighbor x.x.x.x

OS10(conf-router-neighbor)# address-family ipv4 unicast

OS10(conf-router-bgp-neighbor-af)# route-map voice-export in

If that doesn't work, I would also recommend what Chris mention and you said you are thinking about to, contact support directly on this issue.

You know what? I don't think the kind of dynamic leaking I wanted to do works on Dell. On Cisco I could slice out a chunk of the routing table and leak it to a non default VRF. Not on OS10. So I went through the table of allowed matches and sets for route leaking and even if I use the prefix list to set the BGP origin and then use another route map to match that, the result is not the whole routing table but not all the routes I need either.

So I'm going to try to leak the /16 as a static route with the next-hop on a loopback. I put the configuration in and the route shows up in the route table. However, I will need to do some testing to see if works the way we need it to.