Hi, Mark
I have a such configure, it works as I wise, just a month ago!
Here is my config:
routing-options {
    interface-routes {
        rib-group inet CT;
    }
    static {
        route 0.0.0.0/0 next-hop 58.215.51.1;
    }
    rib-groups {
        CNC {
            import-rib [ inet.0 cnc.inet.0 ];
            import-policy test;
        }
        CT {
            import-rib [ inet.0 cnc.inet.0 ];
            import-policy test;
        }
    }
}
policy-options {
    policy-statement test {
        term 1 {
            from {
                route-filter 192.168.2.0/24 orlonger;
                route-filter 192.168.3.0/24 orlonger;
            }
            then accept;
        }
        term default {
            then reject;
        }
    }
}

Best Regards,


Jack Xu
Senior Engineer
Tel:(86)-13524613903
QQ:838178533


-----邮件原件-----
发件人: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] 代表 Mark Tees
发送时间: 2014年11月16日 6:45
收件人: Chris Woodfield
抄送: juniper-nsp@puck.nether.net
主题: Re: [j-nsp] Filtering rib-group imported direct routes?

Hi Chris,

In my lab environment (GNS3+Olives) I can apply an import-policy to the 
rib-group that appears to achieve the effect you are after. I vaguely remember 
trying this on an SRX a few years ago and it not working though.

root> show configuration policy-options
policy-statement rib_filter {
    term 1 {
        from {
            protocol direct;
            route-filter 10.1.2.0/30 exact;
        }
        then accept;
    }
    term else {
        then reject;
    }
}

root> show configuration routing-options
interface-routes {
    rib-group inet TEST;
}
rib-groups {
    TEST {
        import-rib [ inet.0 test.inet.0 ];
        import-policy rib_filter;
    }
}

root> show configuration routing-instances
test {
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop 10.1.2.2;
        }
    }
}

root> show route

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.1.1.0/30        *[Direct/0] 00:34:34
                    > via em0.0
10.1.1.1/32        *[Local/0] 00:34:34
                      Local via em0.0
10.1.2.0/30        *[Direct/0] 00:34:34
                    > via em1.0
10.1.2.1/32        *[Local/0] 00:34:34
                      Local via em1.0
10.10.10.1/32      *[Direct/0] 00:34:34
                    > via lo0.0

test.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 00:04:23
                    > to 10.1.2.2 via em1.0
10.1.2.0/30        *[Direct/0] 00:04:23
                    > via em1.0

Hope that works for you.

Mark

On Sun, Nov 16, 2014 at 6:27 AM, Chris Woodfield <rek...@semihuman.com> wrote:
> Hi,
>
> I’m currently managing a setup where we’re at our edge, we're punting packets 
> to a routing-instance based on firewall matches in order to separate traffic 
> between outside client traffic (which needs to be routed through the LB on 
> return) and other internet-facing outbound. We have rib-groups configured for 
> our routing-instances to import the direct and local routes, like the below 
> (simplified) config example:
>
> routing-options {
>     interface-routes {
>         rib-group {
>             inet fbf-groups;
>         }
>     }
>     ...
>     rib-groups {
>         fbf-groups {
>             import-rib [ inet.0 lb1.inet.0 ]
>         }
>     }
> }
> ...
> firewall {
>     family inet {
>         filter BOUNCE_TO_LB
>             from {
>                 protocol tcp;
>                 source-port [ 80 443 ];
>             }
>             then {
>                 routing-instance lb1;
>             }
>         }
>     }
> }
> ...
> routing-instances {
>     lb1 {
>         instance-type forwarding;
>         routing-options {
>             static {
>                 route 0.0.0.0/0 next-hop 1.2.3.4;
>             }
>         }
>     }
> }
>
> The "lb1" routing-instance is simply a default route to the LB's gateway IP 
> which is a directly connected interface to the router.
>
> (This design is documented here: 
> https://www.juniper.net/documentation/en_US/junos12.3/topics/example/l
> ogical-systems-filter-based-forwarding.html)
>
> The problem I'm having is that because this setup imports all direct and 
> local routes into the routing instance, packets that are punted to the 
> routing instance that are destined for other directly connected hosts bypass 
> the default route and get forwarded directly to the end host. For example, if 
> I have a host hanging off of interface xe-2/0/0 with address 2.2.3.4/24, and 
> I look in the routing-instance's table, I see:
>
> edge-rtr> show route table lb1.inet.0
>
> lb.inet.0: XXX destinations, XXX routes (XXX active, 0 holddown, X 
> hidden)
> + = Active Route, - = Last Active, * = Both
>
> 0.0.0.0/0          *[Static/5] 37w1d 15:53:29
>                     > to 1.2.3.4 via xe-1/0/0
> 2.2.3.4/24         *[Direct/0] 11w3d 10:42:47
>                     > via xe-2/0/0.0
> 2.2.3.1/32         *[Local/0] 11w3d 10:42:47
>                       Local via xe-2/0/0.0
>
> So a packet with dest IP 2.2.3.4 goes directly to the host instead of going 
> to the LB, which means it has the real host IP and not the VIP's IP as its 
> source, which means no worky worky.
>
> So the question I have is this - is there a way to filter the direct and 
> local routes that are imported into a routing instance? In this case, I'd 
> only want the direct route for the subnet containing 1.2.3.4, and no other 
> direct routes.
>
> Alternatively, would it be possible to *not* import any direct routes into 
> the routing-instance (i.e. deleting the rib-groups syntax altogether) and 
> instead add the direct and/or local route manually to the routing instance, 
> so I can ensure that only the direct routes I need to resolve the next hop 
> make it into the routing instance?
>
> TIA,
>
> -Chris
>
>
>
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> https://puck.nether.net/mailman/listinfo/juniper-nsp



--
Regards,

Mark L. Tees

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net 
https://puck.nether.net/mailman/listinfo/juniper-nsp


_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Reply via email to