Re: [j-nsp] Filtering rib-group imported direct routes?

2014-11-15 Thread Mark Tees
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/logical-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,


Re: [j-nsp] Filtering rib-group imported direct routes?

2014-11-15 Thread Phil Bedard
Can you apply an import policy to the rib group to weed those out?  Also the 
newer versions of Junos support Cisco PBR like functionality straight from the 
firewall filter instead of having to deal with the instances, so traffic goes 
directly out an interface vs. being subject to LPM in another routing table.  

Phil

-Original Message-
From: Chris Woodfield rek...@semihuman.com
Sent: ‎11/‎15/‎2014 3:14 PM
To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Subject: [j-nsp] Filtering rib-group imported direct routes?

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/logical-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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Filtering rib-group imported direct routes?

2014-11-15 Thread Hugo Slabbert
Mark's message already covered the rib-group interface routes option, but I 
thought I'd chime in with the option of doing this through instance-import 
under the FBF itself without rib-groups.


Sorry; sent this earlier but from a non-list address.  Original message 
follows below:

--

You can apply import policy to rib-groups or otherwise use instance-import 
in the FBF.  Either one gives you more granularity than just straight-up 
interface route leaking.


For policy on rib-groups, you would do something like:

routing-options {
   interface-routes {
   rib-group {
   inet fbf-groups;
   }
   }
   ...
   rib-groups {
   fbf-groups {
   import-rib [ inet.0 lb1.inet.0 ]
   import-policy lb1-default-direct;
   }
   }
}
...
policy-options {
   policy-statement lb1-default-direct {
   term direct {
   from protocol direct;
   from interface xe-1/0/0.0
   then accept;
   }
   then reject;
   }
}

instance-import is more granular still.  Disclaimer: I've only used 
instance-import to leak routes from virtual-router instances to FBFs; I 
have not used it to leak routes from inet.0 to an FBF, so take this with a 
grain of salt.


For that you would skip the rib-groups and instead would do something like:

policy-options {
   policy-statement lb1-fbf-import {
   term inet0-default-direct {
   from {
   instance lb1;
   protocol direct;
   interface xe-1/0/0.0;
   }
   then accept;
   }
   term else-reject {
   then reject;
   }
   }
}
...
routing-instances {
   lb1 {
   instance-type forwarding;
   routing-options {
   static {
   route 0.0.0.0/0 next-hop 1.2.3.4;
   }
   instance-import lb1-fbf-import;
   }
   }
}

Cheers,

Hugo

Chris Woodfield rek...@semihuman.com wrote on Sat [2014-Nov-15 11:27:03 
-0800]:

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/logical-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