Simple FBF Not Working

could you post the config of show routing-options ?

hoogen82 wrote: »

could you post the config of show routing-options ?

Sure

static {
route 172.30.0.0/16 next-hop 172.30.1.2;
route 0.0.0.0/0 next-hop 172.30.1.2;
}

Could you also post the show route output from your router... You seem to be missing some alot of configurations here...

Also do post the whole configuration... do not edit the output since this is just a lab config...

This is on a production unit. We have JTAC support so we are going to call them if we can't figure this out, but I thought it may be something simple. Here is the config with some changes to the IPs and other stuff, however I kept it as close to the original as possible. The above commands were removed when they did not work so they don't appear here.

<Removed Config>

i hate reading the config like that, so i'm going to jump to my first guess instead of studying that config. someone can correct me on whatever i missed

i don't see ge-2/0/2.0 and ge-2/0/20.1200 defined in a security zone. this will default them to to the null "goodbye all packets" zone. create address book entries and a security policy to allow the traffic.

also, you use: route 0.0.0.0/0 next-hop 172.30.4.2
set interfaces ge-2/0/2 unit 0 family inet address 172.30.200.1/24
set interfaces ge-2/0/20 unit 1200 family inet address 172.30.253.0/31

how is the instance going to resolve the next-hop of 172.30.4.2? your interfaces are in different subnets.

and now that i think of it, shouldn't the ip addresses and vlans for those interfaces be defined under the routing-instances stanza and not in the main configuration, which would put them in the main inet.0 table?

it's been awhile since i did the fbf, but this just doesn't look right, i could be forgetting how to do it though

i have my fbf configs on my other laptop unfortunately. doh.

i guess you did say you scrubbed the configs and changed some ips, so maybe that's some of what i'm seeing

alright. i think i'm off here and i'm confusing a few different things together. i knew i should have taken that nap instead of logging onto this site.

so anyhoo, here's an actual guide showing you how to do it on the srx.

Juniper Networks - How to configure Filter Based Forwarding on SRX for a typical dual-ISP scenario - Knowledge Base

hope this helps!

Very cool document....

And that's exactly why I was asking routing-options configuration...

Missing the rib-groups here.. and lots of good stuff...

The document provided by Zoidberg is spot on... You may want to avoid the JTAC and just get it resolved yourself...

Do also delete the configuration of this page... Looks like TW Telecom...

hoogen82 wrote: »

Very cool document....

And that's exactly why I was asking routing-options configuration...

Missing the rib-groups here.. and lots of good stuff...

The document provided by Zoidberg is spot on... You may want to avoid the JTAC and just get it resolved yourself...

Do also delete the configuration of this page... Looks like TW Telecom...

I changed it IPs and ASs and yes we use TW Telecom.

I have only made a few changes to this SRX since I got here. Most of that config was done by someone who thankfully is now gone. I have glanced over the rib-groups but did not think they would be necessary for this case, but will take a closer look. I used the display set as this takes up less room to print. Thanks guys, I'll look over your suggestions.

So adding this allowed the ToAthena routing table to show up.

interface-routes {
rib-group inet IMPORT-RIB;
}
rib-groups {
IMPORT-RIB {
import-rib [ ToAthena.inet.0 inet.0];
}
}

So it looks like the routing table has to be associated with an interface? I am assuming that is what the interface-routes stanza does.

We really don't need the entire default routing table to be shared with the ToAthena routing table, is there another cleaner way to do this?

The interface routes import direct routes / interface routes to the new routing table... Have you checked.. there shouldn't be the whole thing in my opinion...

i believe you can use a policy here to control which routes are imported

hoogen82 wrote: »

The interface routes import direct routes / interface routes to the new routing table... Have you checked.. there shouldn't be the whole thing in my opinion...

You are absolutely correct, it is just the connected interfaces. I am playing with this on an SRX 250 where the entire table is directly connected interfaces.

See if I have this right. The ToAthena routing table did no show up because the only route in it pointed to an address that could not be resolved as that address/subnet did not exist in the ToAthena table. Using the 'rib import' and 'interface routes' allowed directly connected routes to be shared from the default table into the ToAthena table. Those two commands are still a bit of a mystery in exactly what they do.

Here is the complete config with the filter. We will try this on our production unit once we get out of freeze next week.

set routing-instances ToAthena instance-type forwarding routing-options static route 0.0.0.0/0 next-hop 172.30.4.2
set firewall filter AthenaDR term redirect from source-address 172.21.70.7
set firewall filter AthenaDR term redirect then routing-instance ToAthena
set firewall filter AthenaDR term allow-all then accept
set interfaces ge-0/0/0.0 family inet filter input AthenaDR
set routing-options rib-groups IMPORT import-rib inet.0
set routing-options rib-groups IMPORT import-rib ToAthena.inet.0
set routing-options rib-groups IMPORT import-policy proxy-interface
set routing-options interface-routes rib-group inet IMPORT
set policy-options policy-statement proxy-interface term service from interface ge-0/0/2.0
set policy-options policy-statement proxy-interface term service to rib ToAthena.inet.0
set policy-options policy-statement proxy-interface term service then accept
set policy-options policy-statement proxy-interface term reject then reject

Thanks everyone for your help with this, I will post the results.

Just wanted to let you all know the config above worked. Thanks again.