Re: [j-nsp] filter based forwarding of self-generated traffic

[Alexander Arseniev]

Hello,

FBF for self-originated traffic is not supported.

The technical explanation is that all filters bar one are instantiated 
in the forwarding plane but self-generated traffic is routed & 
L2-encapsulated by RE itself.


The only filter that is instantiated in the RE is fxp0 filter.

Your best bet would be to have primary ISP in the custom routing 
instance but secondary ISP in the GRT. Then You CAN have ALL 
self-generated traffic to go via secondary ISP.


Sure, You can route SOME self-generated traffic via custom routing 
instance (like sending SNMP traps, or NTP server) but not all, notable 
exception is RADIUS/TACACS for login authentication.


HTH

Thx

Alex


On 07/12/2017 15:14, Daniel Hagerty wrote:

[ Please pardon any duplication, it looks like my first post attempt
was scrubbed. ]

 I have built up a lab to test a configuration where I'd like an
srx240 to route some of its self generated to a secondary ISP via
filter based forwarding.  I'm utterly failing at this.

 I can trivially get the config to work as I want for other hosts
being forwarded by the srx, but not the srx's own traffic.  srx
traffic that meets filter forwarding criteria always receives
"Operation not permitted" error messages, as if there's a default
reject somewhere that I haven't found.

 Can anybody tell me what I'm missing here?  I've tried fiddling
many ways and have yet to figure it out.  The seemingly relevant bits
of config are below.  Thanks in advance.

version 12.3X48-D50.6;
security {
 policies {
 from-zone internet to-zone internet {
 policy sure {
 match {
 source-address any;
 destination-address any;
 application any;
 }
 then {
 permit;
 }
 }
 }
 from-zone internet to-zone inside {
 policy sure {
 match {
 source-address any;
 destination-address any;
 application any;
 }
 then {
 permit;
 }
 }
 }
 from-zone inside to-zone internet {
 policy sure {
 match {
 source-address any;
 destination-address any;
 application any;
 }
 then {
 permit;
 }
 }
 }
 from-zone junos-host to-zone internet {
 policy sure {
 match {
 source-address any;
 destination-address any;
 application any;
 }
 then {
 permit;
 }
 }
 }
 from-zone internet to-zone junos-host {
 policy sure {
 match {
 source-address any;
 destination-address any;
 application any;
 }
 then {
 permit;
 }
 }
 }
 from-zone inside to-zone junos-host {
 policy sure {
 match {
 source-address any;
 destination-address any;
 application any;
 }
 then {
 permit;
 }
 }
 }
 from-zone junos-host to-zone inside {
 policy sure {
 match {
 source-address any;
 destination-address any;
 application any;
 }
 then {
 permit;
 }
 }
 }
 }
 zones {
 security-zone internet {
 host-inbound-traffic {
 system-services {
 all;
 }
 }
 interfaces {
 ge-0/0/1.0;
 ge-0/0/2.0;
 }
 }
 security-zone inside {
 host-inbound-traffic {
 system-services {
 all;
 }
 }
 interfaces {
 ge-0/0/0.0;
 }
 }
 }
}
interfaces {
 ge-0/0/0 {
 description "Faux Internal";
 unit 0 {
 family inet {
 inactive: filter {
 input forward;
 }
 address 192.168.1.1/24;
 }
 }
 }
 ge-0/0/1 {
 description "Faux isp1 ethernet";
 unit 0 {
 family inet {
 address 172.22.1.2/24;
 }
 }
 }
 ge-0/0/2 {
 description "Faux isp2 ethernet";
 unit 

Re: [j-nsp] Filter based forwarding for IPv6 with SRX

[Ola Thoresen]

On 17. sep. 2016 02:59, Jason Healy wrote:

On Sep 15, 2016, at 10:19 AM, Mircho Mirchev  wrote:

Has someone ever tried to do FBF for inet6 on SRX?

(...)


If the SRX is anything like the QFX, then you are likely out of luck.




I haven't tested this on either platform, but from my experience,the 
QFX5100 has some limitations due to chipset issues.  We have experienced 
similar cases, where the config is accepted and commits fine, but where 
the features are not actually implemented (an no warnings are isssued 
either).


So I would expect this to work on an SRX - at least if the config is 
allowed.



Rgds.

/Ola Thoresen

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

Re: [j-nsp] Filter based forwarding for IPv6 with SRX

[Jason Healy]

On Sep 15, 2016, at 10:19 AM, Mircho Mirchev  wrote:
> 
> Has someone ever tried to do FBF for inet6 on SRX?

I don't have an SRX, but we do have a QFX5100.  We tried to set up IPv6 FBF 
and, although the configuration is accepted, it does not work.  We've raised 
this issue up the chain at Juniper and have essentially been told that the 
switch is working "as advertised" and that the "feature" is not present on this 
platform.

Of course, this wasn't noted in the documentation, isn't prevented from the 
configuration, and we were sold the QFX to overcome IPv6 issues we'd had on the 
EX4500.  So that meant a lot of wasted time and frustration for us when we hit 
this issue.

If the SRX is anything like the QFX, then you are likely out of luck.

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

Re: [j-nsp] filter-based forwarding... struggling

[ryanL]

hi. just to close the loop on this issue - my configuration was correct. i
opened a case with JTAC and we narrowed it down to the PFE being stupid.
once we restarted the PFE proc the packets arrived at my proxy as desired.

thanks to those who helped, and hopefully this helps someone else in the
future! a very frustrating few days, indeed.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] filter-based forwarding... struggling

[Matjaz Straus Istenic]

On 15. feb. 2014, at 09:24, ryanL ryan.lan...@gmail.com wrote:

 isn't that accomished essentially with the interface-routes stanza, or is my 
 interpretation off?

Your interpretation is fine. I've missed that. Sorry for misleading you.
So, you do have a route for the next-hop in the nat-vrf.inet.0:
# show route forwarding-table table nat-vrf destination 10.1.5.11

...and 10.1.5.11 does not resolve? Have you verified Olivier's suggestion yet?

Cheers,
Matjaž
 
 On Friday, February 14, 2014, Matjaz Straus Istenic mat...@njetwork.si 
 wrote:
 On 15. feb. 2014, at 08:19, Matjaz Straus Istenic mat...@njetwork.si wrote:
 
  Maybe you should install local (interface) router in your nat-vrt routing 
  instance as well.
 Fat fingers and fast typing, I had direct _routes_ in mind. For example:
 
 policy-statement ... {
 
 term InstallLocal {
 from {
 protocol direct;
 route-filter ...;
 }
 to rib nat-vrf.inet.0;
 then accept;
 }
 
 
  Or, at least the ones your need -- the vlan.105.
 
  Cheers,
Matjaž
 
 
 
 -- 
 ..mobile ryry..



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] filter-based forwarding... struggling

[ryanL]

isn't that accomished essentially with the interface-routes stanza, or is
my interpretation off?

On Friday, February 14, 2014, Matjaz Straus Istenic mat...@njetwork.si
wrote:

 On 15. feb. 2014, at 08:19, Matjaz Straus Istenic 
 mat...@njetwork.sijavascript:;
 wrote:

  Maybe you should install local (interface) router in your nat-vrt
 routing instance as well.
 Fat fingers and fast typing, I had direct _routes_ in mind. For example:

 policy-statement ... {
 
 term InstallLocal {
 from {
 protocol direct;
 route-filter ...;
 }
 to rib nat-vrf.inet.0;
 then accept;
 }


  Or, at least the ones your need -- the vlan.105.
 
  Cheers,
Matjaž



-- 
..mobile ryry..
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] filter-based forwarding... struggling

[Olivier Benghozi]

You have to add:
set firewall filter FLEET-NAT term else-nat then accept


By the way in 12.2R2 and later you can as well drop all this 
rib-group+forwarding instance stuff, and just replace then routing-instance 
nat-vrf by then next-ip 10.1.0.51 in your firewall filter, as in a PBR Cisco 
like config.


regards,
Olivier

Le 15 févr. 2014 à 01:41, ryanL ryan.lan...@gmail.com a écrit :

 hi. this should be dead simple, but it isn't and my google-fu is sucking.
 
 all i want to do on my ex4500 is punt traffic to a next hop. simple
 policy-based routing in cisco-speak. apparently you need a routing-instance
 to do so. fine. we'll try it.
 
 so here we go. i'm basically saying if the destination isn't other fleet
 machines in 10/8, or the source isn't any of my public ip, throw it at my
 proxy/nat box that lives at 10.1.0.51, which is learned via bgp (exabgp).
 for now, i'm testing this only on one machine - 10.1.12.2, as referenced in
 the firewall filter.
 
 // config //
 
 routing-instances {
nat-vrf {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 10.1.0.51;
}
}
}
 }
 routing-options {
interface-routes {
rib-group inet fbf-group;
}
rib-groups {
fbf-group {
import-rib [ inet.0 nat-vrf.inet.0 ];
}
}
 }
 protocols {
bgp {
group NAT-VIP {
family inet {
unicast {
rib-group fbf-group;
}
}
}
}
 }
 
 interfaces {
vlan {
unit 112 {
family inet {
filter {
input FLEET-NAT;
}
}
}
}
 }
 
 firewall {
filter FLEET-NAT {
term pass-1 {
from {
source-address {
snip;
}
}
then accept;
}
term pass-2 {
from {
destination-address {
10.0.0.0/8;
}
}
then accept;
}
term else-nat {
from {
source-address {
10.1.12.2/32;
}
}
then {
log;
routing-instance nat-vrf;
}
}
}
}
 }
 // end //
 
 the routing instance nat-vrf sees the route to 10.1.0.51:
 
 # show route table nat-vrf 10.1.0.51
 
 nat-vrf.inet.0: 61 destinations, 62 routes (61 active, 0 holddown, 0 hidden)
 + = Active Route, - = Last Active, * = Both
 
 10.1.0.51/32   *[BGP/170] 00:36:53, localpref 500
  AS path: I, validation-state: unverified
 to 10.1.5.11 via vlan.105
 
 and we have a recursed route to the 10.1.5.11 next hop.
 
 # show route table nat-vrf 10.1.5.11
 
 nat-vrf.inet.0: 61 destinations, 62 routes (61 active, 0 holddown, 0 hidden)
 + = Active Route, - = Last Active, * = Both
 
 10.1.5.0/24*[Direct/0] 00:41:46
 via vlan.105
 
 forwarding table looks ok, i think:
 
 # show route forwarding-table table nat-vrf destination 10.1.0.51
 Routing table: nat-vrf.inet
 Internet:
 DestinationType RtRef Next hop   Type Index NhRef Netif
 10.1.0.51/32   user 0indr 131083 5
  10.1.5.11  ucst  1639 4 vlan.105
 
 # show route forwarding-table table nat-vrf destination 10.1.5.11
 Routing table: nat-vrf.inet
 Internet:
 DestinationType RtRef Next hop   Type Index NhRef Netif
 10.1.5.0/24user 0rtbl 129
 
 i think the thing missing here is that nat-vrf doesn't have a mac address
 next-hop for 10.1.5.11/32, much like inet.0 does:
 
 # show route forwarding-table destination 10.1.5.11
 Routing table: default.inet
 Internet:
 DestinationType RtRef Next hop   Type Index NhRef Netif
 10.1.5.11/32   dest 1 0:25:90:19:93:ca   ucst  1639 4 vlan.105
 
 so, when tcpdumping on 10.1.5.11, i see no packets come in from a fleet
 machine as i'd expect.
 
 the firewall log shows my curl attempts to google, so i know i'm making it
 into the else-nat term properly.
 
 # show firewall log
 Log :
 Time  FilterAction Interface ProtocolSrc Addr
  Dest Addr
 23:55:55  pfe   A  xe-0/0/12.0   TCP 10.1.12.2
   74.125.228.230
 23:55:54  pfe   A  xe-0/0/12.0   TCP 10.1.12.2
   74.125.228.230
 
 i'm a bit stumped from this point forward. i entirely admit that i don't
 necessarily understand some of the knobs to turn with this setup. i did at
 least try changing the routing-instance from forwarding to
 virtual-router.
 
 not quite sure how to get nat-vrf to actually do the f part. do i have to
 

Re: [j-nsp] filter-based forwarding... struggling

[Olivier Benghozi]

Damn, next-ip is MX only :/
And accept is implicit anyway in the term for matched packets.

But, shouldn't you have a resolve for your 0.0.0.0/0 static route in your 
forwarding instance?


Le 16 févr. 2014 à 04:01, ryanL ryan.lan...@gmail.com a écrit :

 hi olivier.
 
 it doesn't appear that next-ip is available on the EX platform; i'm running 
 12.3R3.4 and that doesn't show up.
 
 also, setting term else-nat then accept ends up removing term else-nat 
 then routing-instance nat-vrf. i don't believe you can have both.
 
 thx
 
 ryan
 
 
 
 On Sat, Feb 15, 2014 at 6:30 PM, Olivier Benghozi 
 olivier.bengh...@wifirst.fr wrote:
 You have to add:
 set firewall filter FLEET-NAT term else-nat then accept
 
 
 By the way in 12.2R2 and later you can as well drop all this 
 rib-group+forwarding instance stuff, and just replace then routing-instance 
 nat-vrf by then next-ip 10.1.0.51 in your firewall filter, as in a PBR 
 Cisco like config.
 
 
 regards,
 Olivier
 
 Le 15 févr. 2014 à 01:41, ryanL ryan.lan...@gmail.com a écrit :
 
  hi. this should be dead simple, but it isn't and my google-fu is sucking.
 
  all i want to do on my ex4500 is punt traffic to a next hop. simple
  policy-based routing in cisco-speak. apparently you need a routing-instance
  to do so. fine. we'll try it.
 
  so here we go. i'm basically saying if the destination isn't other fleet
  machines in 10/8, or the source isn't any of my public ip, throw it at my
  proxy/nat box that lives at 10.1.0.51, which is learned via bgp (exabgp).
  for now, i'm testing this only on one machine - 10.1.12.2, as referenced in
  the firewall filter.
 
  // config //
 
  routing-instances {
 nat-vrf {
 instance-type forwarding;
 routing-options {
 static {
 route 0.0.0.0/0 next-hop 10.1.0.51;
 }
 }
 }
  }
  routing-options {
 interface-routes {
 rib-group inet fbf-group;
 }
 rib-groups {
 fbf-group {
 import-rib [ inet.0 nat-vrf.inet.0 ];
 }
 }
  }
  protocols {
 bgp {
 group NAT-VIP {
 family inet {
 unicast {
 rib-group fbf-group;
 }
 }
 }
 }
  }
 
  interfaces {
 vlan {
 unit 112 {
 family inet {
 filter {
 input FLEET-NAT;
 }
 }
 }
 }
  }
 
  firewall {
 filter FLEET-NAT {
 term pass-1 {
 from {
 source-address {
 snip;
 }
 }
 then accept;
 }
 term pass-2 {
 from {
 destination-address {
 10.0.0.0/8;
 }
 }
 then accept;
 }
 term else-nat {
 from {
 source-address {
 10.1.12.2/32;
 }
 }
 then {
 log;
 routing-instance nat-vrf;
 }
 }
 }
 }
  }
  // end //
 
  the routing instance nat-vrf sees the route to 10.1.0.51:
 
  # show route table nat-vrf 10.1.0.51
 
  nat-vrf.inet.0: 61 destinations, 62 routes (61 active, 0 holddown, 0 hidden)
  + = Active Route, - = Last Active, * = Both
 
  10.1.0.51/32   *[BGP/170] 00:36:53, localpref 500
   AS path: I, validation-state: unverified
  to 10.1.5.11 via vlan.105
 
  and we have a recursed route to the 10.1.5.11 next hop.
 
  # show route table nat-vrf 10.1.5.11
 
  nat-vrf.inet.0: 61 destinations, 62 routes (61 active, 0 holddown, 0 hidden)
  + = Active Route, - = Last Active, * = Both
 
  10.1.5.0/24*[Direct/0] 00:41:46
  via vlan.105
 
  forwarding table looks ok, i think:
 
  # show route forwarding-table table nat-vrf destination 10.1.0.51
  Routing table: nat-vrf.inet
  Internet:
  DestinationType RtRef Next hop   Type Index NhRef Netif
  10.1.0.51/32   user 0indr 131083 5
   10.1.5.11  ucst  1639 4 vlan.105
 
  # show route forwarding-table table nat-vrf destination 10.1.5.11
  Routing table: nat-vrf.inet
  Internet:
  DestinationType RtRef Next hop   Type Index NhRef Netif
  10.1.5.0/24user 0rtbl 129
 
  i think the thing missing here is that nat-vrf doesn't have a mac address
  next-hop for 10.1.5.11/32, much like inet.0 does:
 
  # show route forwarding-table destination 10.1.5.11
  Routing table: default.inet
  Internet:
  DestinationType RtRef Next hop   Type Index NhRef Netif
  10.1.5.11/32   dest 1 0:25:90:19:93:ca   ucst  1639 4 vlan.105
 
  so, when tcpdumping on 10.1.5.11, i see no packets come in from 

Re: [j-nsp] filter-based forwarding... struggling

[Matjaz Straus Istenic]

Maybe you should install local (interface) router in your nat-vrt routing 
instance as well.
Or, at least the ones your need -- the vlan.105.

Cheers,
Matjaž

On 15. feb. 2014, at 01:41, ryanL ryan.lan...@gmail.com wrote:

 hi. this should be dead simple, but it isn't and my google-fu is sucking.
 
 all i want to do on my ex4500 is punt traffic to a next hop. simple
 policy-based routing in cisco-speak. apparently you need a routing-instance
 to do so. fine. we'll try it.
 
 so here we go. i'm basically saying if the destination isn't other fleet
 machines in 10/8, or the source isn't any of my public ip, throw it at my
 proxy/nat box that lives at 10.1.0.51, which is learned via bgp (exabgp).
 for now, i'm testing this only on one machine - 10.1.12.2, as referenced in
 the firewall filter.
 
 // config //
 
 routing-instances {
nat-vrf {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 10.1.0.51;
}
}
}
 }
 routing-options {
interface-routes {
rib-group inet fbf-group;
}
rib-groups {
fbf-group {
import-rib [ inet.0 nat-vrf.inet.0 ];
}
}
 }
 protocols {
bgp {
group NAT-VIP {
family inet {
unicast {
rib-group fbf-group;
}
}
}
}
 }
 
 interfaces {
vlan {
unit 112 {
family inet {
filter {
input FLEET-NAT;
}
}
}
}
 }
 
 firewall {
filter FLEET-NAT {
term pass-1 {
from {
source-address {
snip;
}
}
then accept;
}
term pass-2 {
from {
destination-address {
10.0.0.0/8;
}
}
then accept;
}
term else-nat {
from {
source-address {
10.1.12.2/32;
}
}
then {
log;
routing-instance nat-vrf;
}
}
}
}
 }
 // end //
 
 the routing instance nat-vrf sees the route to 10.1.0.51:
 
 # show route table nat-vrf 10.1.0.51
 
 nat-vrf.inet.0: 61 destinations, 62 routes (61 active, 0 holddown, 0 hidden)
 + = Active Route, - = Last Active, * = Both
 
 10.1.0.51/32   *[BGP/170] 00:36:53, localpref 500
  AS path: I, validation-state: unverified
 to 10.1.5.11 via vlan.105
 
 and we have a recursed route to the 10.1.5.11 next hop.
 
 # show route table nat-vrf 10.1.5.11
 
 nat-vrf.inet.0: 61 destinations, 62 routes (61 active, 0 holddown, 0 hidden)
 + = Active Route, - = Last Active, * = Both
 
 10.1.5.0/24*[Direct/0] 00:41:46
 via vlan.105
 
 forwarding table looks ok, i think:
 
 # show route forwarding-table table nat-vrf destination 10.1.0.51
 Routing table: nat-vrf.inet
 Internet:
 DestinationType RtRef Next hop   Type Index NhRef Netif
 10.1.0.51/32   user 0indr 131083 5
  10.1.5.11  ucst  1639 4 vlan.105
 
 # show route forwarding-table table nat-vrf destination 10.1.5.11
 Routing table: nat-vrf.inet
 Internet:
 DestinationType RtRef Next hop   Type Index NhRef Netif
 10.1.5.0/24user 0rtbl 129
 
 i think the thing missing here is that nat-vrf doesn't have a mac address
 next-hop for 10.1.5.11/32, much like inet.0 does:
 
 # show route forwarding-table destination 10.1.5.11
 Routing table: default.inet
 Internet:
 DestinationType RtRef Next hop   Type Index NhRef Netif
 10.1.5.11/32   dest 1 0:25:90:19:93:ca   ucst  1639 4 vlan.105
 
 so, when tcpdumping on 10.1.5.11, i see no packets come in from a fleet
 machine as i'd expect.
 
 the firewall log shows my curl attempts to google, so i know i'm making it
 into the else-nat term properly.
 
 # show firewall log
 Log :
 Time  FilterAction Interface ProtocolSrc Addr
  Dest Addr
 23:55:55  pfe   A  xe-0/0/12.0   TCP 10.1.12.2
   74.125.228.230
 23:55:54  pfe   A  xe-0/0/12.0   TCP 10.1.12.2
   74.125.228.230
 
 i'm a bit stumped from this point forward. i entirely admit that i don't
 necessarily understand some of the knobs to turn with this setup. i did at
 least try changing the routing-instance from forwarding to
 virtual-router.
 
 not quite sure how to get nat-vrf to actually do the f part. do i have to
 share arp across instances somehow as well?
 
 appreciate any pointers!
 
 ryan
 ___
 juniper-nsp mailing list 

Re: [j-nsp] filter-based forwarding... struggling

[Matjaz Straus Istenic]

On 15. feb. 2014, at 08:19, Matjaz Straus Istenic mat...@njetwork.si wrote:

 Maybe you should install local (interface) router in your nat-vrt routing 
 instance as well.
Fat fingers and fast typing, I had direct _routes_ in mind. For example:

policy-statement ... {

term InstallLocal {
from {
protocol direct;
route-filter ...;
}
to rib nat-vrf.inet.0;
then accept;
}


 Or, at least the ones your need -- the vlan.105.
 
 Cheers,
   Matjaž



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Filter based forwarding issue

[Jonathan Looney]

It apears term 3 is far below term 1 and term 2. It appears ping and
Telnet traffic from 192.168.4.128/26 would match terms ping and telnet;
therefore, they will never hit term 3 and not use filter-based forwarding.

Does this explain the behavior you are seeing?

If so, I believe the configuration-mode command insert firewall filter
next-hop-office-DMZservers term 3 after term 2 will solve this problem.

-Jon

On Thu, Sep 27, 2012 at 11:26 AM, Brendan Regan brendan.bre...@gmail.comwrote:


 firewall {
 filter next-hop-office-DMZservers {
 inactive: term allow-all-traffic {
 then accept;
 }
 term 1 {
 from {
 source-address {
 192.168.4.0/26;
 212.111.101.0/27;
 }
 }
 then {
 routing-instance 4.0/26-source;
 }
 }
 term 2 {
 from {
 source-address {
 192.168.4.64/26;
 }
 }
 then {
 routing-instance 4.64/26-source;
 }
 }
 term telnet {
 from {
 source-address {
 212.111.102.0/24;
 192.168.4.0/24;
 }
 protocol tcp;
 port telnet;
 }
 then accept;
 }
 term ping {
 from {
 source-address {
 212.111.102.0/24
 192.168.4.0/24;

 }
 protocol icmp;
 }
 then accept;
 }
 term snmp {
 from {
 source-address {
 212.111.102.0/24
 }
 protocol udp;
 port snmp;
 }
 then accept;
 }
 term http {
 from {
 source-address {
 212.111.102.0/24
 }
 protocol tcp;
 port http;
 }
 then accept;
 }
 term 3 {
 from {
 source-address {
 192.168.4.128/26;
 }
 }
 then {
 routing-instance PDU1178;
 }
 }
 term accept-remaining-traffic {
 then {
 count remaining-traffic-counter;
 accept;
 }
 }
 }
 }

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

Re: [j-nsp] Filter-based forwarding outside of inet.0?

[Clarke Morledge]

Thanks to Stacy and Hendri, I got this to work perfectly!   This really 
helped.


Since it does not hurt to have more examples (as they are non-existent in 
the Junos docs for this particular type of application - Boo Hoo!!!), I am 
including the recipe/configuration solution below..


Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187



DefaultRoute  via  192.168.0.1
^
|
|
   xe-11/0/0.40
|
Downstream: 192.168.99.2  xe-9/0/0.40 VirtualRtr
|
 irb.42
|
|
v
 Hijack via 192.168.255.1



By default, I have a static route in a routing instance (VirtualRtr) 
sending the default route to 192.168.0.1.  I want to hijack traffic 
matching a particular filter and send the traffic to a different next-hop, 
192.168.255.1.


For you Cisco types, this is basically equivalent to using a route-map for 
setting the next hop:


route-map VirtualRtr-Redirect permit 100
 match ip address hijack-acl
 set ip vrf VirtualRtr next-hop 192.168.255.1

Whereas in the Cisco world, you would need to create an ACL and apply that 
with the route-map to the incoming interface, in Junos you create a filter 
and apply the filter to the interface:


[edit firewall family inet filter fbf-redirect-filter]
term t1 {
from {
address {
192.168.99.2/32;
}
}
then {
routing-instance fbf-test;
}
}
term t2 {
then accept;
}

[edit interfaces xe-9/0/0 unit 40]
vlan-id 40;
family inet {
filter {
input fbf-redirect-filter;
}
address 192.168.99.1/30;
}

At this point, Junos is more complex as it adds a layer of abstraction 
with the concept of rib-groups.  You create your rib group by importing 
FIRST the table belonging to your virtual router and SECOND the table for 
the forwarding instance that has the next-hop specified:


[edit routing-options]
rib-groups {
fbf-rib-test {
import-rib [ VirtualRtr.inet.0 fbf-test.inet.0 ];
}
}


So here is the forwarding routing instance that defines the next-hop IP. 
But you'll need to make sure you can resolve the next-hop, so you 
associate the interface-routes with the rib-group you've created within 
the virtual routing instance:



[edit routing-instances fbf-test]
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 192.168.255.1;  ## PBR-like next-hop
}
}

[edit routing-instances VirtualRtr]
instance-type virtual-router;
interface xe-9/0/0.40;
interface xe-11/0/0.40;
interface irb.42;
routing-options {
interface-routes {
rib-group inet fbf-rib-test;
static {
route 0.0.0.0/0 next-hop 192.168.0.1;  ## Normal next-hop
}
}

In my case above, the 192.168.255.1 is hanging off of the irb.42 
interface.   Everything resolves in the routing tables:


show route table VirtualRtr

0.0.0.0/0  *[Static/5] 25w4d 07:20:38
 to 192.168.0.1 via xe-11/0/0.40

show route table fbf-test

0.0.0.0/0  *[Static/5] 00:54:31
 to 192.168.255.1 via irb.42

And also you can verify the forwarding entries (my IRB is part of a vpls 
interface, hence the reference to the lsi):


show route forwarding-table table VirtualRtr
Routing table: VirtualRtr.inet
Internet:
DestinationType RtRef Next hop   Type Index NhRef Netif
defaultuser 0 0:23:9c:10:10:40   ucst  183639 
xe-11/0/0.40

defaultperm 0rjct   643 2
0.0.0.0/32 perm 0dscd   641 1

show route forwarding-table table fbf-test
Routing table: fbf-test.inet
Internet:
DestinationType RtRef Next hop   Type Index NhRef Netif
defaultuser 0 0:10:db:ee:10:0ucst  4721 3 
lsi.1048729

defaultperm 0rjct  7005 2
0.0.0.0/32 perm 0dscd  6937 1



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

Re: [j-nsp] Filter-based forwarding outside of inet.0?

[Stacy W. Smith]

Hi Clarke,

1) The rib group must be defined under the main instance [edit routing-options 
rib-groups] .
2) The import-rib line in the rib group definition must list the VRF routing 
table first, and the FBF routing table second.
3) The rib group must be applied within the VRF [edit routing-instances VRF 
[edit routing-options interface-routes rib-group inet].


Here's an example, using instance-type virtual-router, but the same principles 
should apply to instance-type vrf:

1) Traffic enters the foo routing-instance on fe-2/0/2.10.
2) If traffic is sourced from 192.168.1.3/32 the next hop is 192.168.3.2 via 
fe-2/0/2.30.
3) If traffic is source from any other address, the next hop is 192.168.2.2 via 
fe-2/0/2.20.

user@host show configuration interfaces fe-2/0/2 
vlan-tagging;
unit 10 {
vlan-id 10;
family inet {
filter {
input bar;  firewall filter applied to ingress 
traffic
}
address 192.168.1.1/24;
}
}
unit 20 {
vlan-id 20;
family inet {
address 192.168.2.1/24;
}
}
unit 30 {
vlan-id 30;
family inet {
address 192.168.3.1/24;
}
}

user@host show configuration routing-options
rib-groups {
fbf {   rib group defined in 
master instance
import-rib [ foo.inet.0 fbf.inet.0 ];   vr table 1st, fbf 
table 2nd
}
}

user@host show configuration routing-instances  
fbf {  forwarding instance
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop 192.168.3.2;   next-hop only 
reachable via foo.inet.0
}
}
}
foo {vr instance
instance-type virtual-router;
interface fe-2/0/2.10;  ingress interface
interface fe-2/0/2.20;  1st egress interface
interface fe-2/0/2.30;  2nd egress interface
routing-options {
interface-routes {
rib-group inet fbf;   copy interface routes to 
fbf.inet.0 using the fbf rib group 
}
static {
route 0.0.0.0/0 next-hop 192.168.2.2;   default route for 
traffic that's accepted by the bar firewall filter
}
}
}

user@host show configuration firewall 
family inet {
filter bar {
term 1 {
from {  criteria for traffic that 
should be forwarded via FBF
source-address {
192.168.1.3/32;
}
}
then {
routing-instance fbf;using fbf.inet.0 for forwarding 
lookup
}
}
term 2 {
then accept;accept everything else and use default 
foo.inet.0 for forwarding lookup
}
}
}

user@host show route table foo 

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

0.0.0.0/0  *[Static/5] 00:45:34
 to 192.168.2.2 via fe-2/0/2.20default 
route for non fbf traffic
192.168.1.0/24 *[Direct/0] 00:57:20
 via fe-2/0/2.10
192.168.1.1/32 *[Local/0] 00:57:20
  Local via fe-2/0/2.10
192.168.2.0/24 *[Direct/0] 00:57:20
 via fe-2/0/2.20
192.168.2.1/32 *[Local/0] 00:57:20
  Local via fe-2/0/2.20
192.168.3.0/24 *[Direct/0] 00:57:20
 via fe-2/0/2.30
192.168.3.1/32 *[Local/0] 00:57:20
  Local via fe-2/0/2.30


user@host show route table fbf

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

0.0.0.0/0  *[Static/5] 00:37:17
 to 192.168.3.2 via fe-2/0/2.30   default route 
for fbf traffic
192.168.1.0/24 *[Direct/0] 00:37:17
 via fe-2/0/2.10
192.168.1.1/32 *[Local/0] 00:37:17
  Local via fe-2/0/2.10
192.168.2.0/24 *[Direct/0] 00:37:17
 via fe-2/0/2.20
192.168.2.1/32 *[Local/0] 00:37:17
  Local via fe-2/0/2.20
192.168.3.0/24 *[Direct/0] 00:37:17
 via fe-2/0/2.30
192.168.3.1/32 *[Local/0] 00:37:17
  Local via fe-2/0/2.30


Hope this helps. If the FBF next-hop is across the MPLS core and learned via 
MP-BGP, you might have to get a little more creative in the application of your 
rib-group, but otherwise the same concepts should apply.

Let me know if you hit any more roadblocks.

--Stacy


On Jan 31, 2012, at 4:16 PM, Clarke Morledge wrote:

 I am still trying to wrap my head around FBF, and I am stuck on how to 
 achieve a Cisco-like PBR forcing a packet that matches a set of conditions to 
 go to a different next-hop inside a VRF.  The problem I have is when the new 
 next-hop can only be resolved within the VRF, NOT the default routing 
 instance (inet.0).
 
 Let's say I am trying to create this forwarding 

Re: [j-nsp] Filter-based forwarding outside of inet.0?

[Hendri Sugilar]

Hi Clarke ,

I believe it will work if you just slightly configured interface-routes on
the vrf itself and combine it with fbf using rib-group on the master
routing-instance without inet.0 table is imported . Let me know if it's
helped and work on your side too , below is the complete configuration

[ edit interfaces ]

[edit routing-instaces]
fbf-test {
routing-options {
static {
route 0.0.0.0/0 next-hop 100.100.100.2;
}
}
}
test {
instance-type virtual-router;
interface fe-1/3/0.100;
routing-options {
interface-routes {
rib-group inet fbf-rib-test;
}
}
}

[edit routing-options ]
rib-groups {
fbf-rib-test {
import-rib [ fbf-test.inet.0 test.inet.0 ];
}
}


Log below is verified next-hop is reachable through interfaces within
interfaces inside vrf :

 show route table test

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

100.100.100.0/30 *[Direct/0] 00:00:09
 via fe-1/3/0.100
100.100.100.1/32 *[Local/0] 00:00:09
Local via fe-1/3/0.100

 show route table fbf-test

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

0.0.0.0/0 *[Static/5] 00:00:21
 to 100.100.100.2 via fe-1/3/0.100
100.100.100.0/30 *[Direct/0] 00:00:21
 via fe-1/3/0.100
100.100.100.1/32 *[Local/0] 00:00:21
Local via fe-1/3/0.100



Thanks

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

Re: [j-nsp] Filter-based forwarding on egress - limitations on the MX?

[Tarique A. Nalkhande - BMC]

Clarke,

If I understood your query correctly, IMHO you would also want to explore the 
option of putting this FBF filter under PFE itself (forwarding-option).

--- sample output ---

MX-960 show configuration forwarding-options family inet filter 
input FBF-Filter;

MX-960 show configuration firewall family inet filter FBF-Filter  
term redirect-term {
filter redirect-to-Securitybox;
}
term accept-all-without-redirection {
then {
count accept;
}
}

MX-960 show configuration firewall family inet filter redirect-to-Securitybox 
term egress {
from {
source-prefix-list {
redirected-prefixes-security;
}
}
then {
count xyz;
routing-instance redirected-prefixes-security;
}
}
term ingress {
from {
destination-prefix-list {
redirected-prefixes-security;
}
}
then {
count xyz;
routing-instance redirected-prefixes-security;
}
}

MX-960 show configuration routing-instances redirect-to-Securitybox 
instance-type vrf;
route-distinguisher ;
vrf-import ;
vrf-export ;
vrf-table-label;
routing-options {
static {
route 0.0.0.0/0 {
next-hop security-box-ip;
}
}
}

MX-960 show configuration routing-options rib-groups interface-routes  
  
import-rib [ inet.0 redirect-to-Securitybox.inet.0]
import-policy import-connected-to-Security


MX-960 show configuration routing-options
interface-routes {
rib-group inet interface-routes;
}

MX-960 show configuration policy-options policy-statement 
import-connected-to-Security  
term inet.0 {
to rib inet.0;
then accept;
}
term connected-to-security {
from {
protocol direct;
interface x; -- Your preferred exit interface 
}
to rib redirect-to-Securitybox.inet.0;
then accept;
}
-  ---

Hope it helps!!!


Thanks  Regards
Tarique Abbas Nalkhande


-Original Message-
From: juniper-nsp-boun...@puck.nether.net 
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Clarke Morledge
Sent: 22 April, 2011 5:29 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Filter-based forwarding on egress - limitations on the MX?

I am trying to wrap my head around the limitations regarding filter-based 
forwarding for egress packets, on the output of a layer3 interface, on 
the MX platform.

Early on in Junos, filter-based forwarding (or policy-based routing in 
the Cisco context) you could only do filter-based forwarding on ingress 
into the router.   Now, apparently you can do filter-based forwarding on 
the output interface:

http://www.juniper.net/techpubs/en_US/junos10.2/information-products/topic-collections/config-guide-network-interfaces/topic-25474.html

Aside from some limitations with source-class usage filter matching and 
uRPF checks, I am wondering if there are any gotchas here.

Let's say I have an application where I have a security box for scrubbing 
packets hanging off of an MX.  I want to redirect some traffic matching a 
particular filter term along a single egress path out of the router to go 
out instead via a different interface to hit my security box.  However, 
packets along this single egress path might have multiple points of entry 
coming into the router.  It would be difficult to scale putting an input 
filter on all of those different ingress interfaces.  It would be really 
handy and simple to just apply an output filter on the single output 
interface to redirect my traffic.

But are there crazy things that happen under the covers that could cause 
problems?   Is the output filter really just an input filter applied to 
all other interfaces?   What if my ingress packets that follow this path 
come into the router via different shapes and sizes; i.e. straight IP, or 
having an MPLS header, or maybe even a GRE tunnel terminated on the 
router.   Would the output filter still work as I expect?

The documentaton regarding filter-based forwarding on output interface 
suggest that this can be applied to port-mirror traffic, but would this 
also work for my security box redirection application?

Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

--Disclaimer-- This email and any files transmitted with are classified 
as confidential unless otherwise specified. This e-mail is intended solely for 
the use of the individual or entity to whom this e-mail is addressed. If you 
have received this email by mistake, please notify the sender and delete this 
e-mail immediately and permanently. Although measures were taken to free this 
e-mail and its attachments from any 

Re: [j-nsp] Filter Based Forwarding with bgp import rib

[Doan Nguyen]

Hi,

are you basically trying to redirect traffic from host and internet to take a 
detour box access server not shown on the topo, that is strictly hanging off 
from
router A?  All your FBF needs to happen on router A if you're to enforce 
traffic 
to take a detour to your local access server.  


In this case I think you have the host to internet FBF on Router B vs. Router 
A.  Even thought the RI in B forces all traffic to 172.16.0.2 which is in 
router 
a,
the traffic enters the RI and leaves it arriving at Router A.  When Router A 
gets the packet then the source/destination is still from 5.5.5.5 to 0/0 and 
forwards
that straight out to 1.1.1/x using inet.0.  What you need is to move your FBF 
on 
B to A and have the firewall input on A's link to B.  That way you can force 
the 
outbound
traffic to take your access server vs. using inet.0.

-Doan




From:Mohammad Salbad salbad1...@hotmail.com
To: juniper-nsp@puck.nether.net
Sent: Thu, March 24, 2011 10:19:45 AM
Subject: [j-nsp] Filter Based Forwarding with bgp import rib

Hi All



I have the following setup

Internet  .1- - - - 1.1.1.0/30 - - - - .2 RouterA  .1 - - 10.0.0.0/30 - - .2
RouterB .5 - - 10.0.0.4/30 - - .6 routerC  .1 - - - -  5.5.5.5/24 Host

RouterA is connected to an access server and the access server has a LAN
(172.16.0.2/30) and WAN (172.16.1.2/30) interface.

RouterA has a default route from 1.1.1.1 and it is advertised to routerB
through ibgp

RouterA and routerB are running ibgp between themselves

Access Server LAN and WAN interface are advertised from routerA to routerB
through ibgp

Link between routerB and routerC (10.0.0.4/30) is advertised from routerB to
routerA through ibgp

5.5.5.0/24 is advertised from routerB to routerA through ibgp

RouterB has a static route to 5.5.5.0/24 pointing to routerC

RouterC has a default route pointing to RouterB (10.0.0.5)

Access server has a default route pointing to routerA (172.16.1.1/30)

Access server has a static route to 5.5.5.0/24 pointing to routerA
(172.16.0.1/30)

Requirement

Traffic from host 5.5.5.5 to the internet shall follow the following path

Host à RouterC à RouterB à RouterA à Access Server LAN à Access Server WAN à
routerA à Internet

Traffic from the internet to host 5.5.5.5 shall follow the following path

Internet à routerA à Access Server WAN à Access Server LAN à RouterA à
RouterB àRouterC à Host



What I’ve done so far to achieve the above requirements:

I’ve added a static route on routerA to reach 5.5.5.0/24 go to Access Server
LAN (172.16.0.2), this route will be more preferred than the ibgp route
advertised by routerB

I’ve applied a filter based forwarding on routerA interface that is facing
the Access Server LAN interface as following:

-  Source: 0.0.0.0/0

-  Destination: 5.5.5.0/24

-  Next-Hop: 10.0.0.6 (RouterC) with the resolve option

Since 10.0.0.6 is known to routerA via ibgp I did an import for bgp routes
to the routing instance used in the FBF

I’ve also applied a filter based forwarding on routerB interface that is
facing routerC interface as following:

-  Source: 5.5.5.0/24

-  Destination: 0.0.0.0/0

-  Next-Hop: 172.16.0.2 (Access Server LAN) with the resolve option

And Since 172.16.0.0/30 is known to routerB via ibgp I did an import for bgp
routes to the routing instance used in the FBF



The problem

Traffic from host 5.5.5.5 to the internet is following the below path:

Host à RouterC à RouterB à RouterA à Internet  

I think this is because when the packet reaches routerA it does normal
routing lookup, and it is not aware of the next-hop



Traffic from the internet to host 5.5.5.5 is following the below path:

Internet à routerA à Access Server WAN à Access Server LAN à RouterA à
RouterB à RouterC

Which is OK with me and it is as it should be



So finally my problem is with the traffic from the host to the internet, I
need to force it to go through the access server LAN.



Thank you

Mohammad Salbad







___
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] Filter Based Forwarding with bgp import rib

[Justin M. Streiner]

On Thu, 24 Mar 2011, Doan Nguyen wrote:


are you basically trying to redirect traffic from host and internet to take a
detour box access server not shown on the topo, that is strictly hanging off
from
router A?  All your FBF needs to happen on router A if you're to enforce traffic
to take a detour to your local access server.


In this case I think you have the host to internet FBF on Router B vs. Router
A.  Even thought the RI in B forces all traffic to 172.16.0.2 which is in router
a,
the traffic enters the RI and leaves it arriving at Router A.  When Router A
gets the packet then the source/destination is still from 5.5.5.5 to 0/0 and
forwards
that straight out to 1.1.1/x using inet.0.  What you need is to move 
your FBF on B to A and have the firewall input on A's link to B.  That 
way you can force the

outbound
traffic to take your access server vs. using inet.0.


I've been hunting around for a solution to a similar issue - essentially 
a modified approach to RTBH.  I'd like to be able to redirect or 
optionally port-mirror inbound and outbound traffic to another interface 
on my border router, and the trigger for determining what traffic would be 
affected would be a BGP feed from a route server, and the actions to be 
taken (discard, redirect to another interface, port-mirror to another 
interface) by the border routers could be dictated by BGP community tags.


The issues I've run into with this have been that I couldn't find a way to 
get a Junos firewall filter to see and react to BGP routes and their 
associated community tags.


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

Re: [j-nsp] Filter Based Forwarding with bgp import rib

[Stefan Fouant]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Justin M. Streiner
 Sent: Thursday, March 24, 2011 7:35 AM
 To: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Filter Based Forwarding with bgp import rib
 
 I've been hunting around for a solution to a similar issue -
 essentially
 a modified approach to RTBH.  I'd like to be able to redirect or
 optionally port-mirror inbound and outbound traffic to another
 interface
 on my border router, and the trigger for determining what traffic would
 be
 affected would be a BGP feed from a route server, and the actions to be
 taken (discard, redirect to another interface, port-mirror to another
 interface) by the border routers could be dictated by BGP community
 tags.
 
 The issues I've run into with this have been that I couldn't find a way
 to
 get a Junos firewall filter to see and react to BGP routes and their
 associated community tags.

Hi Justin,

I've done just this very thing for various traffic filtering applications.
Ping me offline and I can provide you some sample configs that should work.
One thing I'd like to point out however, since you mention RTBH, is that I
think you would be better served with BGP FlowSpec in this case, because
RTBH only serves to provide automated distribution of destination-based
filters throughout an environment.  Technically you can do S/RTBH if you
couple RTBH w/ uRPF... nonetheless there are some limitations to this
approach and one of the primary reasons FlowSpec was created in the first
place.  You can filter on source-address, destination-address, protocol,
source-port, and destination-port, or any combination of these.  Much more
flexible in my opinion than simply RTBH, plus it gives you the flexibility
of FBF w/ automation layered on top.  Juniper probably has the best working
implementation of FlowSpec out of any of the vendors out there so you're in
luck here.

I have a presentation on the benefits of FlowSpec on my blog -
http://www.shortestpathfirst.net/presentations/

Stefan Fouant, CISSP, JNCIEx2
www.shortestpathfirst.net
GPG Key ID: 0xB4C956EC

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

Re: [j-nsp] Filter based forwarding

[Nilesh Khambal]

Can you add a default route in virtual-router PBR to point to next-table as
inet.0?

- set virtual-router PBR routing-options static route 0.0.0.0/0 next-table
  inet.0 

You will loose the granularity of defining the source address and port to
forward the traffic but I am not sure if that matters in this case for
reverse traffic. This route will forward all the return traffic received
from port ge-0/1/0 to inet.0 for a second-level lookup if no specific route
is found in PBR.inet.0 routing table.

Thanks,
Nilesh.

On 12/2/09 6:17 PM, Chris Evans chrisccnpsp...@gmail.com wrote:

 Question for you all..
 
 We are a Cisco shop today primary and have some Juniper devices here and there
 in the network. We have started an RFI for our next gen data center and
 Juniper has provided some 8200's and 4200's for us to evaluate. We have come
 up with a complication of how to introduce services into the environment..
 
 Currently we have our server farms based on Cisco Catalyst 6500 switches. For
 our services we have firewalling and load balancing in each server farm.
 Introducing firewalling with an EX platform would not be an issue, however
 load balancing appears to be. To avoic overloading the load balancers we
 policy route select traffic to the load balancer instead of all traffic. In
 general we just policy route http and https traffic to the load balancers
 which then load balances on to the servers. We have to do the PBR ingress into
 the container and also the return traffic from the server, as stateful flow
 must be maintained. The policy apply points are on the layer 3 interfaces
 between the distribution and core, as well as the VLAN interface service the
 server segment. This easy to do in the Cisco world as we can apply a next-hop
 for any traffic we chose via a simple route-map.
 
 Our difficulty comes when implementing this on a JUNOS platform as setting a
 next-hop isn't possible with filter based forwarding. We have created the
 firewall filters classifying the traffic which points it to another
 routing-instance. This piece works fine, however the issues becomes the return
 traffic. As all return traffic is in that routing-instance we have to create
 another filter to punt this traffic back into the global/master
 routing-instance. When you configure a firewall filter for the return traffic
 and specify 'routing-instance master' it states this isn't valid, you cannot
 create a master routing-instance either as its reserved..  It seems this is a
 new thing for Juniper, how it's a new thing I cannot understand.
 
 Looking for details if anyone else has done anything like this. I have fear
 this is another 'enterprise' not carrier feature that Juniper doesn't have. We
 are running into many road blocks with their EX platform that prohibits us
 from using it for our environment. We're finding this product line doesn't
 even have the same level of critical features that a 5 year old Cisco platform
 has. Pretty disappointing :(
 
 Here is the configuration that I did a spare M series box for grins.. Let me
 know what you think and if you have ideas...
 
 Traffic would come into ge-1/3/0 destined for 172.16.1.140 port http, it would
 leave towards the host via ge-0/1/0, return traffic would take this same path
 backwards.
 
 Interface configuration:
 ge-0/1/0 {
 unit 0 {
 family inet {
 filter {
 input RETURN;
 }
 address 172.16.1.129/25;
 }
 }
 }
 ge-1/3/0 {
 unit 0 {
 family inet {
 filter {
 input PBR;
 }
 address 192.168.1.252/24;
 }
 }
 }
 
 Routing-Instance Configuration:
 
 PBR {
 instance-type virtual-router;
 interface ge-0/1/0.0;
 }
 
 Firewall Configuration:
 
 filter RETURN {
 interface-specific;
 term term-1 {
 from {
 source-address {
 172.16.1.128/25;
 }
 protocol tcp;
 source-port http;
 }
 then {
 count RETURN;
 log;
 routing-instance master; ## 'master' is not defined
 }
 }
 term ALL-ELSE {
 then accept;
 }
 }
 
 filter PBR {
 interface-specific;
 term term-1 {
 from {
 destination-address {
 172.16.1.128/25;
 }
 protocol tcp;
 destination-port http;
 }
 then {
 count PBR;
 routing-instance PBR;
 }
 }
 term ALL-ELSE {
 then accept;
 }
 }
 
 
 Thanks
 
 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] Filter based forwarding

[Nilesh Khambal]

On 12/2/09 7:10 PM, Nilesh Khambal nkham...@juniper.net wrote:

 - set virtual-router PBR routing-options static route 0.0.0.0/0 next-table
   inet.0 

Sorry the syntax should be

- set routing-instances PBR routing-options static route 0.0.0.0/0
  next-table inet.0

Thanks,
Nilesh.

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

Re: [j-nsp] Filter based forwarding

[Chris Evans]

Just tried that, no dice.. I also tried 'master.inet.0' with no luck.

If I pull the interfaces out of the global routing instance, I can
successfully use a firewall filter to forward how I need it to.
Unfortunately it just doens't work with interfaces are in the default
instance..

Thanks

Chris


On Wed, Dec 2, 2009 at 10:11 PM, Nilesh Khambal nkham...@juniper.netwrote:




 On 12/2/09 7:10 PM, Nilesh Khambal nkham...@juniper.net wrote:

  - set virtual-router PBR routing-options static route 0.0.0.0/0next-table
inet.0

 Sorry the syntax should be

 - set routing-instances PBR routing-options static route 0.0.0.0/0
  next-table inet.0

 Thanks,
 Nilesh.


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

Re: [j-nsp] Filter based forwarding

[Nilesh Khambal]

So, are you saying that by adding a default route pointing to the inet.0 table 
(default routing table) the return traffic is not getting  routed to via inet.0 
via appropriate egress interface?

Is there any another more specific route in PBR.inet.0 for the return traffic 
destination?

Is there a route for the return traffic destination in inet.0 point to the 
correct egress interface?

Can you post “show route a.b.c.d extensive table PBR.inet.0” and then “show 
route a.b.c.d extensive”?

Thanks,
Nilesh


On 12/2/09 7:21 PM, Chris Evans chrisccnpsp...@gmail.com wrote:

Just tried that, no dice.. I also tried 'master.inet.0' with no luck.

If I pull the interfaces out of the global routing instance, I can successfully 
use a firewall filter to forward how I need it to. Unfortunately it just 
doens't work with interfaces are in the default instance..

Thanks

Chris


On Wed, Dec 2, 2009 at 10:11 PM, Nilesh Khambal nkham...@juniper.net wrote:



On 12/2/09 7:10 PM, Nilesh Khambal nkham...@juniper.net wrote:

 - set virtual-router PBR routing-options static route 0.0.0.0/0 
 http://0.0.0.0/0  next-table
   inet.0

Sorry the syntax should be

- set routing-instances PBR routing-options static route 0.0.0.0/0 
http://0.0.0.0/0
  next-table inet.0

Thanks,
Nilesh.



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

Re: [j-nsp] Filter based forwarding

[Chris Evans]

Yes, you are correct.. it doesn't make it back to the source. I don't have
any active routing protocols at all, so I pasted them all. We're just
relying on the default route and directly connected routes. If I set the
next-hop table to 'master.inet.0' it doesn't install the 0.0.0.0/0 route
into PBR.inet.0 at all..

r...@juniperm7i show route extensive table inet.0

inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
Restart Complete
0.0.0.0/0 (1 entry, 1 announced)
TSI:
KRT in-kernel 0.0.0.0/0 - {192.168.1.1}
*Static Preference: 5
Next hop type: Router, Next hop index: 614
Next-hop reference count: 3
Next hop: 192.168.1.1 via ge-1/3/0.0, selected
State: Active Int Ext
Age: 1:26:03
Task: RT
Announcement bits (1): 0-KRT
AS path: I

192.168.1.0/24 (1 entry, 0 announced)
*Direct Preference: 0
Next hop type: Interface
Next-hop reference count: 1
Next hop: via ge-1/3/0.0, selected
State: Active Int
Age: 1:26:03
Task: IF
AS path: I

192.168.1.252/32 (1 entry, 0 announced)
*Local  Preference: 0
Next hop type: Local
Next-hop reference count: 6
Interface: ge-1/3/0.0
State: Active NoReadvrt Int
Age: 1:26:03
Task: IF
AS path: I



r...@juniperm7i show route extensive table PBR.inet.0

PBR.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
0.0.0.0/0 (1 entry, 1 announced)
TSI:
KRT in-kernel 0.0.0.0/0 - {Table}
*Static Preference: 5
Next table: inet.0
Next-hop reference count: 3
State: Active Int Ext
Age: 22
Task: RT
Announcement bits (1): 0-KRT
AS path: I

172.16.1.128/25 (1 entry, 0 announced)
*Direct Preference: 0
Next hop type: Interface
Next-hop reference count: 1
Next hop: via ge-0/1/0.0, selected
State: Active Int
Age: 3:52:19
Task: IF
AS path: I

172.16.1.129/32 (1 entry, 0 announced)
*Local  Preference: 0
Next hop type: Local
Next-hop reference count: 6
Interface: ge-0/1/0.0
State: Active NoReadvrt Int
Age: 3:52:20
Task: IF
AS path: I





On Wed, Dec 2, 2009 at 10:26 PM, Nilesh Khambal nkham...@juniper.netwrote:

 So, are you saying that by adding a default route pointing to the inet.0
 table (default routing table) the return traffic is not getting  routed to
 via inet.0 via appropriate egress interface?

 Is there any another more specific route in PBR.inet.0 for the return
 traffic destination?

 Is there a route for the return traffic destination in inet.0 point to the
 correct egress interface?

 Can you post “show route a.b.c.d extensive table PBR.inet.0” and then “show
 route a.b.c.d extensive”?

 Thanks,
 Nilesh


 On 12/2/09 7:21 PM, Chris Evans chrisccnpsp...@gmail.com wrote:

 Just tried that, no dice.. I also tried 'master.inet.0' with no luck.

 If I pull the interfaces out of the global routing instance, I can
 successfully use a firewall filter to forward how I need it to.
 Unfortunately it just doens't work with interfaces are in the default
 instance..

 Thanks

 Chris


 On Wed, Dec 2, 2009 at 10:11 PM, Nilesh Khambal nkham...@juniper.net
 wrote:



 On 12/2/09 7:10 PM, Nilesh Khambal nkham...@juniper.net wrote:

  - set virtual-router PBR routing-options static route 0.0.0.0/0 
 http://0.0.0.0/0  next-table
inet.0

 Sorry the syntax should be

 - set routing-instances PBR routing-options static route 0.0.0.0/0 
 http://0.0.0.0/0
   next-table inet.0

 Thanks,
 Nilesh.




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

Re: [j-nsp] Filter based forwarding

[Nilesh Khambal]

What is the destination for the forward traffic? Is it one  of the connected 
IPs on ge-0/1/0? I suspect if the problem is with forward traffic rather than 
return traffic. Can you specify what will be the source and destination for the 
forward and return traffic?

master.inet.0 is not the same as inet.0.  “inet.0” refers to the default 
routing table for IPv4 lookup. “master.inet.0” refers to the IPv4 routing table 
for routing-instance name “master” which you don’t have it configured.

Thanks,
Nilesh.




On 12/2/09 7:39 PM, Chris Evans chrisccnpsp...@gmail.com wrote:

Yes, you are correct.. it doesn't make it back to the source. I don't have any 
active routing protocols at all, so I pasted them all. We're just relying on 
the default route and directly connected routes. If I set the next-hop table to 
'master.inet.0' it doesn't install the 0.0.0.0/0 http://0.0.0.0/0  route into 
PBR.inet.0 at all..

r...@juniperm7i show route extensive table inet.0

inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
Restart Complete
0.0.0.0/0 http://0.0.0.0/0  (1 entry, 1 announced)
TSI:
KRT in-kernel 0.0.0.0/0 http://0.0.0.0/0  - {192.168.1.1}
*Static Preference: 5
Next hop type: Router, Next hop index: 614
Next-hop reference count: 3
Next hop: 192.168.1.1 via ge-1/3/0.0, selected
State: Active Int Ext
Age: 1:26:03
Task: RT
Announcement bits (1): 0-KRT
AS path: I

192.168.1.0/24 http://192.168.1.0/24  (1 entry, 0 announced)
*Direct Preference: 0
Next hop type: Interface
Next-hop reference count: 1
Next hop: via ge-1/3/0.0, selected
State: Active Int
Age: 1:26:03
Task: IF
AS path: I

192.168.1.252/32 http://192.168.1.252/32  (1 entry, 0 announced)
*Local  Preference: 0
Next hop type: Local
Next-hop reference count: 6
Interface: ge-1/3/0.0
State: Active NoReadvrt Int
Age: 1:26:03
Task: IF
AS path: I



r...@juniperm7i show route extensive table PBR.inet.0

PBR.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
0.0.0.0/0 http://0.0.0.0/0  (1 entry, 1 announced)
TSI:
KRT in-kernel 0.0.0.0/0 http://0.0.0.0/0  - {Table}
*Static Preference: 5
Next table: inet.0
Next-hop reference count: 3
State: Active Int Ext
Age: 22
Task: RT
Announcement bits (1): 0-KRT
AS path: I

172.16.1.128/25 http://172.16.1.128/25  (1 entry, 0 announced)
*Direct Preference: 0
Next hop type: Interface
Next-hop reference count: 1
Next hop: via ge-0/1/0.0, selected
State: Active Int
Age: 3:52:19
Task: IF
AS path: I

172.16.1.129/32 http://172.16.1.129/32  (1 entry, 0 announced)
*Local  Preference: 0
Next hop type: Local
Next-hop reference count: 6
Interface: ge-0/1/0.0
State: Active NoReadvrt Int
Age: 3:52:20
Task: IF
AS path: I





On Wed, Dec 2, 2009 at 10:26 PM, Nilesh Khambal nkham...@juniper.net wrote:
So, are you saying that by adding a default route pointing to the inet.0 table 
(default routing table) the return traffic is not getting  routed to via inet.0 
via appropriate egress interface?

Is there any another more specific route in PBR.inet.0 for the return traffic 
destination?

Is there a route for the return traffic destination in inet.0 point to the 
correct egress interface?

Can you post “show route a.b.c.d extensive table PBR.inet.0” and then “show 
route a.b.c.d extensive”?

Thanks,
Nilesh


On 12/2/09 7:21 PM, Chris Evans chrisccnpsp...@gmail.com wrote:

Just tried that, no dice.. I also tried 'master.inet.0' with no luck.

If I pull the interfaces out of the global routing instance, I can successfully 
use a firewall filter to forward how I need it to. Unfortunately it just 
doens't work with interfaces are in the default instance..

Thanks

Chris


On Wed, Dec 2, 2009 at 10:11 PM, Nilesh Khambal nkham...@juniper.net wrote:



On 12/2/09 7:10 PM, Nilesh Khambal nkham...@juniper.net wrote:

 - set virtual-router PBR routing-options static route 0.0.0.0/0 
 http://0.0.0.0/0  http://0.0.0.0/0  next-table
   inet.0

Sorry the syntax should be

- set routing-instances PBR routing-options static route 0.0.0.0/0 
http://0.0.0.0/0  http://0.0.0.0/0
  next-table inet.0

Thanks,
Nilesh.





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

Re: [j-nsp] Filter based forwarding

[Chris Evans]

Here is where I'm coming up with 'master', as you can see below 'master' is
valid. In either case, the src is 192.168.1.210 and destination is
172.16.1.140..  If create another routing-instance such as PBR2 and put
ge-1/3/0 into it and apply the firewall filter, it works properly.. It just
seems that you cannot call the default inet.0 within the firewall filter as
there is no really no instance defined.



r...@juniperm7i# show routing-instances
PBR {
instance-type virtual-router;
interface ge-0/1/0.0;
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
}
}
master {
instance-type virtual-router;
}

[edit]
r...@juniperm7i# commit check
[edit routing-instances]
  'master'
RT Instance: master is a reserved instance name
error: configuration check-out failed




r...@juniperm7i show route instance
Instance Type
 Primary RIB
Active/holddown/hidden
PBR  virtual-router
 PBR.inet.0  3/0/0

__juniper_private1__ forwarding
 __juniper_private1__.inet.0 3/0/1
 __juniper_private1__.inet6.04/0/0

__juniper_private2__ forwarding
 __juniper_private2__.inet.0 0/0/1

__master.anon__  forwarding

master   forwarding
 inet.0  7/0/0
 inet.1  5/0/0
 inet6.0 2/0/0


On Wed, Dec 2, 2009 at 10:44 PM, Nilesh Khambal nkham...@juniper.netwrote:

 What is the destination for the forward traffic? Is it one  of the
 connected IPs on ge-0/1/0? I suspect if the problem is with forward traffic
 rather than return traffic. Can you specify what will be the source and
 destination for the forward and return traffic?

 master.inet.0 is not the same as inet.0.  “inet.0” refers to the default
 routing table for IPv4 lookup. “master.inet.0” refers to the IPv4 routing
 table for routing-instance name “master” which you don’t have it configured.

 Thanks,
 Nilesh.




 On 12/2/09 7:39 PM, Chris Evans chrisccnpsp...@gmail.com wrote:

 Yes, you are correct.. it doesn't make it back to the source. I don't have
 any active routing protocols at all, so I pasted them all. We're just
 relying on the default route and directly connected routes. If I set the
 next-hop table to 'master.inet.0' it doesn't install the 0.0.0.0/0 
 http://0.0.0.0/0  route into PBR.inet.0 at all..

 r...@juniperm7i show route extensive table inet.0

 inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
 Restart Complete
 0.0.0.0/0 http://0.0.0.0/0  (1 entry, 1 announced)
 TSI:
 KRT in-kernel 0.0.0.0/0 http://0.0.0.0/0  - {192.168.1.1}
 *Static Preference: 5
Next hop type: Router, Next hop index: 614
Next-hop reference count: 3
Next hop: 192.168.1.1 via ge-1/3/0.0, selected
State: Active Int Ext
Age: 1:26:03
Task: RT
Announcement bits (1): 0-KRT
AS path: I

 192.168.1.0/24 http://192.168.1.0/24  (1 entry, 0 announced)
 *Direct Preference: 0
Next hop type: Interface
Next-hop reference count: 1
Next hop: via ge-1/3/0.0, selected
State: Active Int
Age: 1:26:03
Task: IF
AS path: I

 192.168.1.252/32 http://192.168.1.252/32  (1 entry, 0 announced)
 *Local  Preference: 0
Next hop type: Local
Next-hop reference count: 6
Interface: ge-1/3/0.0
State: Active NoReadvrt Int
Age: 1:26:03
Task: IF
AS path: I



 r...@juniperm7i show route extensive table PBR.inet.0

 PBR.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
 0.0.0.0/0 http://0.0.0.0/0  (1 entry, 1 announced)
 TSI:
 KRT in-kernel 0.0.0.0/0 http://0.0.0.0/0  - {Table}
 *Static Preference: 5
Next table: inet.0
Next-hop reference count: 3
State: Active Int Ext
Age: 22
Task: RT
Announcement bits (1): 0-KRT
AS path: I

 172.16.1.128/25 http://172.16.1.128/25  (1 entry, 0 announced)
 *Direct Preference: 0
Next hop type: Interface
Next-hop reference count: 1
Next hop: via ge-0/1/0.0, selected
State: Active Int
Age: 3:52:19
Task: IF
AS path: I

 172.16.1.129/32 http://172.16.1.129/32  (1 entry, 0 announced)
 *Local  Preference: 0
Next hop type: Local
Next-hop reference count: 6
Interface: ge-0/1/0.0
State: Active NoReadvrt Int
Age: 3:52:20
 

Re: [j-nsp] Filter based forwarding

[Nilesh Khambal]

Weird. Can you try this configuration instead?

- remove the default route from PBR.
- put ge-1/3/0 in default and ge-0/1/0 in PBR instance.
- keep the filter PBR on ge-1/3/0.
- Add following configuration.

[edit routing-options]
u...@host#

interface-routes {
rib-group inet redist-local-routes;
}

rib-groups {
redist-local-routes {
import-rib [ inet.0 PBR.inet.0 ];
}
}

Then try the traffic again.

Thanks,
Nilesh.




On 12/2/09 8:07 PM, Chris Evans chrisccnpsp...@gmail.com wrote:

 Here is where I'm coming up with 'master', as you can see below 'master' is
 valid. In either case, the src is 192.168.1.210 and destination is
 172.16.1.140..  If create another routing-instance such as PBR2 and put
 ge-1/3/0 into it and apply the firewall filter, it works properly.. It just
 seems that you cannot call the default inet.0 within the firewall filter as
 there is no really no instance defined.
 
 
 
 r...@juniperm7i# show routing-instances
 PBR {
     instance-type virtual-router;
     interface ge-0/1/0.0;
     routing-options {
     static {
     route 0.0.0.0/0 http://0.0.0.0/0  next-table inet.0;
     }
     }
 }
 master {
     instance-type virtual-router;
 }
 
 [edit]
 r...@juniperm7i# commit check
 [edit routing-instances]
   'master'
     RT Instance: master is a reserved instance name
 error: configuration check-out failed
 
 
 
 
 r...@juniperm7i show route instance
 Instance Type
  Primary RIB
 Active/holddown/hidden
 PBR  virtual-router
  PBR.inet.0  3/0/0
 
 __juniper_private1__ forwarding
  __juniper_private1__.inet.0 3/0/1
  __juniper_private1__.inet6.0    4/0/0
 
 __juniper_private2__ forwarding
  __juniper_private2__.inet.0 0/0/1
 
 __master.anon__  forwarding
 
 master   forwarding
  inet.0  7/0/0
  inet.1  5/0/0
  inet6.0 2/0/0
 
 
 On Wed, Dec 2, 2009 at 10:44 PM, Nilesh Khambal nkham...@juniper.net wrote:
 What is the destination for the forward traffic? Is it one  of the connected
 IPs on ge-0/1/0? I suspect if the problem is with forward traffic rather than
 return traffic. Can you specify what will be the source and destination for
 the forward and return traffic?
 
 master.inet.0 is not the same as inet.0.  ³inet.0² refers to the default
 routing table for IPv4 lookup. ³master.inet.0² refers to the IPv4 routing
 table for routing-instance name ³master² which you don¹t have it configured.
 
 Thanks,
 Nilesh.
 
 
 
 
 On 12/2/09 7:39 PM, Chris Evans chrisccnpsp...@gmail.com wrote:
 
 Yes, you are correct.. it doesn't make it back to the source. I don't have
 any active routing protocols at all, so I pasted them all. We're just relying
 on the default route and directly connected routes. If I set the next-hop
 table to 'master.inet.0' it doesn't install the 0.0.0.0/0 http://0.0.0.0/0
 http://0.0.0.0/0  route into PBR.inet.0 at all..
 
 r...@juniperm7i show route extensive table inet.0
 
 inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
 Restart Complete
 0.0.0.0/0 http://0.0.0.0/0  http://0.0.0.0/0  (1 entry, 1 announced)
 TSI:
 KRT in-kernel 0.0.0.0/0 http://0.0.0.0/0  http://0.0.0.0/0  -
 {192.168.1.1}
         *Static Preference: 5
                 Next hop type: Router, Next hop index: 614
                 Next-hop reference count: 3
                 Next hop: 192.168.1.1 via ge-1/3/0.0, selected
                 State: Active Int Ext
                 Age: 1:26:03
                 Task: RT
                 Announcement bits (1): 0-KRT
                 AS path: I
 
 192.168.1.0/24 http://192.168.1.0/24  http://192.168.1.0/24  (1 entry, 0
 announced)
         *Direct Preference: 0
                 Next hop type: Interface
                 Next-hop reference count: 1
                 Next hop: via ge-1/3/0.0, selected
                 State: Active Int
                 Age: 1:26:03
                 Task: IF
                 AS path: I
 
 192.168.1.252/32 http://192.168.1.252/32  http://192.168.1.252/32  (1
 entry, 0 announced)
         *Local  Preference: 0
                 Next hop type: Local
                 Next-hop reference count: 6
                 Interface: ge-1/3/0.0
                 State: Active NoReadvrt Int
                 Age: 1:26:03
                 Task: IF
                 AS path: I
 
 
 
 r...@juniperm7i show route extensive table PBR.inet.0
 
 PBR.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
 0.0.0.0/0 http://0.0.0.0/0  http://0.0.0.0/0  (1 entry, 1 announced)
 TSI:
 KRT in-kernel 0.0.0.0/0 http://0.0.0.0/0  http://0.0.0.0/0  - {Table}
         *Static Preference: 5
                 Next table: inet.0
                 Next-hop 

Re: [j-nsp] Filter based forwarding

[Chris Evans]

Just tried and that appears to work..

Explain as to what an interface-route is?

On Wed, Dec 2, 2009 at 11:14 PM, Nilesh Khambal nkham...@juniper.netwrote:

 Weird. Can you try this configuration instead?

 - remove the default route from PBR.
 - put ge-1/3/0 in default and ge-0/1/0 in PBR instance.
 - keep the filter PBR on ge-1/3/0.
 - Add following configuration.

 [edit routing-options]
 u...@host#

 interface-routes {
rib-group inet redist-local-routes;
 }

 rib-groups {
redist-local-routes {
import-rib [ inet.0 PBR.inet.0 ];
}
 }

 Then try the traffic again.

 Thanks,
 Nilesh.




 On 12/2/09 8:07 PM, Chris Evans chrisccnpsp...@gmail.com wrote:

  Here is where I'm coming up with 'master', as you can see below 'master'
 is
  valid. In either case, the src is 192.168.1.210 and destination is
  172.16.1.140..  If create another routing-instance such as PBR2 and put
  ge-1/3/0 into it and apply the firewall filter, it works properly.. It
 just
  seems that you cannot call the default inet.0 within the firewall filter
 as
  there is no really no instance defined.
 
 
 
  r...@juniperm7i# show routing-instances
  PBR {
  instance-type virtual-router;
  interface ge-0/1/0.0;
  routing-options {
  static {
  route 0.0.0.0/0 http://0.0.0.0/0  next-table inet.0;
  }
  }
  }
  master {
  instance-type virtual-router;
  }
 
  [edit]
  r...@juniperm7i# commit check
  [edit routing-instances]
'master'
  RT Instance: master is a reserved instance name
  error: configuration check-out failed
 
 
 
 
  r...@juniperm7i show route instance
  Instance Type
   Primary RIB
  Active/holddown/hidden
  PBR  virtual-router
   PBR.inet.0  3/0/0
 
  __juniper_private1__ forwarding
   __juniper_private1__.inet.0 3/0/1
   __juniper_private1__.inet6.04/0/0
 
  __juniper_private2__ forwarding
   __juniper_private2__.inet.0 0/0/1
 
  __master.anon__  forwarding
 
  master   forwarding
   inet.0  7/0/0
   inet.1  5/0/0
   inet6.0 2/0/0
 
 
  On Wed, Dec 2, 2009 at 10:44 PM, Nilesh Khambal nkham...@juniper.net
 wrote:
  What is the destination for the forward traffic? Is it one  of the
 connected
  IPs on ge-0/1/0? I suspect if the problem is with forward traffic rather
 than
  return traffic. Can you specify what will be the source and destination
 for
  the forward and return traffic?
 
  master.inet.0 is not the same as inet.0.  ³inet.0² refers to the default
  routing table for IPv4 lookup. ³master.inet.0² refers to the IPv4
 routing
  table for routing-instance name ³master² which you don¹t have it
 configured.
 
  Thanks,
  Nilesh.
 
 
 
 
  On 12/2/09 7:39 PM, Chris Evans chrisccnpsp...@gmail.com wrote:
 
  Yes, you are correct.. it doesn't make it back to the source. I don't
 have
  any active routing protocols at all, so I pasted them all. We're just
 relying
  on the default route and directly connected routes. If I set the
 next-hop
  table to 'master.inet.0' it doesn't install the 0.0.0.0/0 
 http://0.0.0.0/0
  http://0.0.0.0/0  route into PBR.inet.0 at all..
 
  r...@juniperm7i show route extensive table inet.0
 
  inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
  Restart Complete
  0.0.0.0/0 http://0.0.0.0/0  http://0.0.0.0/0  (1 entry, 1
 announced)
  TSI:
  KRT in-kernel 0.0.0.0/0 http://0.0.0.0/0  http://0.0.0.0/0  -
  {192.168.1.1}
  *Static Preference: 5
  Next hop type: Router, Next hop index: 614
  Next-hop reference count: 3
  Next hop: 192.168.1.1 via ge-1/3/0.0, selected
  State: Active Int Ext
  Age: 1:26:03
  Task: RT
  Announcement bits (1): 0-KRT
  AS path: I
 
  192.168.1.0/24 http://192.168.1.0/24  http://192.168.1.0/24  (1
 entry, 0
  announced)
  *Direct Preference: 0
  Next hop type: Interface
  Next-hop reference count: 1
  Next hop: via ge-1/3/0.0, selected
  State: Active Int
  Age: 1:26:03
  Task: IF
  AS path: I
 
  192.168.1.252/32 http://192.168.1.252/32  http://192.168.1.252/32
  (1
  entry, 0 announced)
  *Local  Preference: 0
  Next hop type: Local
  Next-hop reference count: 6
  Interface: ge-1/3/0.0
  State: Active NoReadvrt Int
  Age: 1:26:03
  Task: IF
  AS path: I
 
 
 
  r...@juniperm7i show route extensive table PBR.inet.0
 
  PBR.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
  

Re: [j-nsp] Filter based forwarding

[Nilesh Khambal]

We basically leaked the direct and local routes which are nothing but interface 
routes for the interfaces in main routing instance from inet.0 to PBR.inet.0 
table using rib-groups configuration. So the destination route which is 
directly connected to ge-1/3/0 is now appearing as a local route in PBR.inet.0. 
Looks like the next-table route had some limitations when routing the traffic 
to inet.0 table from PBR.inet.0 for connected routes. I can't  think of any 
such limitation as of now. The new configuration pretty much achieved the same 
in a different way. May be next-table method needs some more investigation to 
see if it is really supported in this scenario and if there are any known 
limitations in that area. You can do that by opening a case with JTAC.

Thanks,
Nilesh.


--
Sent from my mobile handheld device

On Dec 2, 2009, at 8:27 PM, Chris Evans 
chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com wrote:

Just tried and that appears to work..

Explain as to what an interface-route is?

On Wed, Dec 2, 2009 at 11:14 PM, Nilesh Khambal 
mailto:nkham...@juniper.netnkham...@juniper.netmailto:nkham...@juniper.net
 wrote:
Weird. Can you try this configuration instead?

- remove the default route from PBR.
- put ge-1/3/0 in default and ge-0/1/0 in PBR instance.
- keep the filter PBR on ge-1/3/0.
- Add following configuration.

[edit routing-options]
u...@host#

interface-routes {
   rib-group inet redist-local-routes;
}

rib-groups {
   redist-local-routes {
   import-rib [ inet.0 PBR.inet.0 ];
   }
}

Then try the traffic again.

Thanks,
Nilesh.




On 12/2/09 8:07 PM, Chris Evans 
mailto:chrisccnpsp...@gmail.comchrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com
 wrote:

 Here is where I'm coming up with 'master', as you can see below 'master' is
 valid. In either case, the src is 192.168.1.210 and destination is
 172.16.1.140..  If create another routing-instance such as PBR2 and put
 ge-1/3/0 into it and apply the firewall filter, it works properly.. It just
 seems that you cannot call the default inet.0 within the firewall filter as
 there is no really no instance defined.



 r...@juniperm7i# show routing-instances
 PBR {
 instance-type virtual-router;
 interface ge-0/1/0.0;
 routing-options {
 static {
 route 0.0.0.0/0http://0.0.0.0/0 
 http://0.0.0.0/0http://0.0.0.0/0  next-table inet.0;
 }
 }
 }
 master {
 instance-type virtual-router;
 }

 [edit]
 r...@juniperm7i# commit check
 [edit routing-instances]
   'master'
 RT Instance: master is a reserved instance name
 error: configuration check-out failed




 r...@juniperm7i show route instance
 Instance Type
  Primary RIB
 Active/holddown/hidden
 PBR  virtual-router
  PBR.inet.0  3/0/0

 __juniper_private1__ forwarding
  __juniper_private1__.inet.0 3/0/1
  __juniper_private1__.inet6.04/0/0

 __juniper_private2__ forwarding
  __juniper_private2__.inet.0 0/0/1

 __master.anon__  forwarding

 master   forwarding
  inet.0  7/0/0
  inet.1  5/0/0
  inet6.0 2/0/0


 On Wed, Dec 2, 2009 at 10:44 PM, Nilesh Khambal 
 mailto:nkham...@juniper.netnkham...@juniper.netmailto:nkham...@juniper.net
  wrote:
 What is the destination for the forward traffic? Is it one  of the connected
 IPs on ge-0/1/0? I suspect if the problem is with forward traffic rather than
 return traffic. Can you specify what will be the source and destination for
 the forward and return traffic?

 master.inet.0 is not the same as inet.0.  ³inet.0² refers to the default
 routing table for IPv4 lookup. ³master.inet.0² refers to the IPv4 routing
 table for routing-instance name ³master² which you don¹t have it configured.

 Thanks,
 Nilesh.




 On 12/2/09 7:39 PM, Chris Evans 
 mailto:chrisccnpsp...@gmail.comchrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com
  wrote:

 Yes, you are correct.. it doesn't make it back to the source. I don't have
 any active routing protocols at all, so I pasted them all. We're just relying
 on the default route and directly connected routes. If I set the next-hop
 table to 'master.inet.0' it doesn't install the 0.0.0.0/0http://0.0.0.0/0 
 http://0.0.0.0/0http://0.0.0.0/0
 http://0.0.0.0/0http://0.0.0.0/0  route into PBR.inet.0 at all..

 r...@juniperm7i show route extensive table inet.0

 inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
 Restart Complete
 0.0.0.0/0http://0.0.0.0/0 http://0.0.0.0/0http://0.0.0.0/0  
 http://0.0.0.0/0http://0.0.0.0/0  (1 entry, 1 announced)
 TSI:
 KRT in-kernel 0.0.0.0/0http://0.0.0.0/0 
 http://0.0.0.0/0http://0.0.0.0/0  http://0.0.0.0/0http://0.0.0.0/0  
 -
 {192.168.1.1}
  

Re: [j-nsp] Filter based forwarding

[Chris Evans]

Interesting..
Will update my SE on this and have him work with JTAC..

On Wed, Dec 2, 2009 at 11:45 PM, Nilesh Khambal nkham...@juniper.netwrote:

 We basically leaked the direct and local routes which are nothing but
 interface routes for the interfaces in main routing instance from inet.0 to
 PBR.inet.0 table using rib-groups configuration. So the destination route
 which is directly connected to ge-1/3/0 is now appearing as a local route in
 PBR.inet.0. Looks like the next-table route had some limitations when
 routing the traffic to inet.0 table from PBR.inet.0 for connected routes. I
 can't  think of any such limitation as of now. The new configuration pretty
 much achieved the same in a different way. May be next-table method needs
 some more investigation to see if it is really supported in this scenario
 and if there are any known limitations in that area. You can do that by
 opening a case with JTAC.

 Thanks,
 Nilesh.


 --
 Sent from my mobile handheld device

 On Dec 2, 2009, at 8:27 PM, Chris Evans chrisccnpsp...@gmail.com
 mailto:chrisccnpsp...@gmail.com wrote:

 Just tried and that appears to work..

 Explain as to what an interface-route is?

 On Wed, Dec 2, 2009 at 11:14 PM, Nilesh Khambal mailto:
 nkham...@juniper.netnkham...@juniper.netmailto:nkham...@juniper.net
 wrote:
 Weird. Can you try this configuration instead?

 - remove the default route from PBR.
 - put ge-1/3/0 in default and ge-0/1/0 in PBR instance.
 - keep the filter PBR on ge-1/3/0.
 - Add following configuration.

 [edit routing-options]
 u...@host#

 interface-routes {
   rib-group inet redist-local-routes;
 }

 rib-groups {
   redist-local-routes {
   import-rib [ inet.0 PBR.inet.0 ];
   }
 }

 Then try the traffic again.

 Thanks,
 Nilesh.




 On 12/2/09 8:07 PM, Chris Evans mailto:chrisccnpsp...@gmail.com
 chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com wrote:

  Here is where I'm coming up with 'master', as you can see below 'master'
 is
  valid. In either case, the src is 192.168.1.210 and destination is
  172.16.1.140..  If create another routing-instance such as PBR2 and put
  ge-1/3/0 into it and apply the firewall filter, it works properly.. It
 just
  seems that you cannot call the default inet.0 within the firewall filter
 as
  there is no really no instance defined.
 
 
 
  r...@juniperm7i# show routing-instances
  PBR {
  instance-type virtual-router;
  interface ge-0/1/0.0;
  routing-options {
  static {
  route 0.0.0.0/0http://0.0.0.0/0 http://0.0.0.0/0
 http://0.0.0.0/0  next-table inet.0;
  }
  }
  }
  master {
  instance-type virtual-router;
  }
 
  [edit]
  r...@juniperm7i# commit check
  [edit routing-instances]
'master'
  RT Instance: master is a reserved instance name
  error: configuration check-out failed
 
 
 
 
  r...@juniperm7i show route instance
  Instance Type
   Primary RIB
  Active/holddown/hidden
  PBR  virtual-router
   PBR.inet.0  3/0/0
 
  __juniper_private1__ forwarding
   __juniper_private1__.inet.0 3/0/1
   __juniper_private1__.inet6.04/0/0
 
  __juniper_private2__ forwarding
   __juniper_private2__.inet.0 0/0/1
 
  __master.anon__  forwarding
 
  master   forwarding
   inet.0  7/0/0
   inet.1  5/0/0
   inet6.0 2/0/0
 
 
  On Wed, Dec 2, 2009 at 10:44 PM, Nilesh Khambal mailto:
 nkham...@juniper.netnkham...@juniper.netmailto:nkham...@juniper.net
 wrote:
  What is the destination for the forward traffic? Is it one  of the
 connected
  IPs on ge-0/1/0? I suspect if the problem is with forward traffic rather
 than
  return traffic. Can you specify what will be the source and destination
 for
  the forward and return traffic?
 
  master.inet.0 is not the same as inet.0.  ³inet.0² refers to the default
  routing table for IPv4 lookup. ³master.inet.0² refers to the IPv4
 routing
  table for routing-instance name ³master² which you don¹t have it
 configured.
 
  Thanks,
  Nilesh.
 
 
 
 
  On 12/2/09 7:39 PM, Chris Evans mailto:chrisccnpsp...@gmail.com
 chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com wrote:
 
  Yes, you are correct.. it doesn't make it back to the source. I don't
 have
  any active routing protocols at all, so I pasted them all. We're just
 relying
  on the default route and directly connected routes. If I set the
 next-hop
  table to 'master.inet.0' it doesn't install the 0.0.0.0/0
 http://0.0.0.0/0 http://0.0.0.0/0http://0.0.0.0/0
  http://0.0.0.0/0http://0.0.0.0/0  route into PBR.inet.0 at all..
 
  r...@juniperm7i show route extensive table inet.0
 
  inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
  Restart 

Re: [j-nsp] Filter based forwarding

[Chris Evans]

Interesting point you bring up about the directly connected interfaces.. I
went back and just did the 0.0.0.0/0 to inet.0. (also without the rib-group
configuration) and did a connection sourcing from a different subnet than
the local interface. It luckily worked, so I agree with you on the directly
connected interface.

This is 9.6R2.11 code..

On Wed, Dec 2, 2009 at 11:51 PM, Chris Evans chrisccnpsp...@gmail.comwrote:

 Interesting..
 Will update my SE on this and have him work with JTAC..


 On Wed, Dec 2, 2009 at 11:45 PM, Nilesh Khambal nkham...@juniper.netwrote:

 We basically leaked the direct and local routes which are nothing but
 interface routes for the interfaces in main routing instance from inet.0 to
 PBR.inet.0 table using rib-groups configuration. So the destination route
 which is directly connected to ge-1/3/0 is now appearing as a local route in
 PBR.inet.0. Looks like the next-table route had some limitations when
 routing the traffic to inet.0 table from PBR.inet.0 for connected routes. I
 can't  think of any such limitation as of now. The new configuration pretty
 much achieved the same in a different way. May be next-table method needs
 some more investigation to see if it is really supported in this scenario
 and if there are any known limitations in that area. You can do that by
 opening a case with JTAC.

 Thanks,
 Nilesh.


 --
 Sent from my mobile handheld device

 On Dec 2, 2009, at 8:27 PM, Chris Evans chrisccnpsp...@gmail.com
 mailto:chrisccnpsp...@gmail.com wrote:

 Just tried and that appears to work..

 Explain as to what an interface-route is?

 On Wed, Dec 2, 2009 at 11:14 PM, Nilesh Khambal mailto:
 nkham...@juniper.netnkham...@juniper.netmailto:nkham...@juniper.net
 wrote:
 Weird. Can you try this configuration instead?

 - remove the default route from PBR.
 - put ge-1/3/0 in default and ge-0/1/0 in PBR instance.
 - keep the filter PBR on ge-1/3/0.
 - Add following configuration.

 [edit routing-options]
 u...@host#

 interface-routes {
   rib-group inet redist-local-routes;
 }

 rib-groups {
   redist-local-routes {
   import-rib [ inet.0 PBR.inet.0 ];
   }
 }

 Then try the traffic again.

 Thanks,
 Nilesh.




 On 12/2/09 8:07 PM, Chris Evans mailto:chrisccnpsp...@gmail.com
 chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com wrote:

  Here is where I'm coming up with 'master', as you can see below 'master'
 is
  valid. In either case, the src is 192.168.1.210 and destination is
  172.16.1.140..  If create another routing-instance such as PBR2 and put
  ge-1/3/0 into it and apply the firewall filter, it works properly.. It
 just
  seems that you cannot call the default inet.0 within the firewall filter
 as
  there is no really no instance defined.
 
 
 
  r...@juniperm7i# show routing-instances
  PBR {
  instance-type virtual-router;
  interface ge-0/1/0.0;
  routing-options {
  static {
  route 0.0.0.0/0http://0.0.0.0/0 http://0.0.0.0/0
 http://0.0.0.0/0  next-table inet.0;
  }
  }
  }
  master {
  instance-type virtual-router;
  }
 
  [edit]
  r...@juniperm7i# commit check
  [edit routing-instances]
'master'
  RT Instance: master is a reserved instance name
  error: configuration check-out failed
 
 
 
 
  r...@juniperm7i show route instance
  Instance Type
   Primary RIB
  Active/holddown/hidden
  PBR  virtual-router
   PBR.inet.0  3/0/0
 
  __juniper_private1__ forwarding
   __juniper_private1__.inet.0 3/0/1
   __juniper_private1__.inet6.04/0/0
 
  __juniper_private2__ forwarding
   __juniper_private2__.inet.0 0/0/1
 
  __master.anon__  forwarding
 
  master   forwarding
   inet.0  7/0/0
   inet.1  5/0/0
   inet6.0 2/0/0
 
 
  On Wed, Dec 2, 2009 at 10:44 PM, Nilesh Khambal mailto:
 nkham...@juniper.netnkham...@juniper.netmailto:nkham...@juniper.net
 wrote:
  What is the destination for the forward traffic? Is it one  of the
 connected
  IPs on ge-0/1/0? I suspect if the problem is with forward traffic
 rather than
  return traffic. Can you specify what will be the source and destination
 for
  the forward and return traffic?
 
  master.inet.0 is not the same as inet.0.  ³inet.0² refers to the
 default
  routing table for IPv4 lookup. ³master.inet.0² refers to the IPv4
 routing
  table for routing-instance name ³master² which you don¹t have it
 configured.
 
  Thanks,
  Nilesh.
 
 
 
 
  On 12/2/09 7:39 PM, Chris Evans mailto:chrisccnpsp...@gmail.com
 chrisccnpsp...@gmail.commailto:chrisccnpsp...@gmail.com wrote:
 
  Yes, you are correct.. it doesn't make it back to the source. I don't
 have
  any active routing protocols at all, so 

Re: [j-nsp] Filter based forwarding and SCU/DCU

[Alex]

SCU/DCU works only in output FW filters
http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-collections/config-guide-policy/policy-configuring-match-conditions-in-firewall-filter-terms.html#id-10823080
You can specify a source class or destination class for an output firewall 
filter. Although you can specify a source class and destination class for an 
input firewall filter, the counters are incremented only if the firewall 
filter is applied on the output interface.


The class-based filter match condition works only for output filters because 
the source class usage (SCU) and destination class usage (DCU) are 
determined after route lookup.


HTH

Cheers

Alex




- Original Message - 
From: Ioan Branet ioan.bra...@gmail.com

To: juniper-nsp juniper-nsp@puck.nether.net
Sent: Wednesday, October 07, 2009 2:40 PM
Subject: [j-nsp] Filter based forwarding and SCU/DCU



   }Hello,

Does anyone configured filter based forwarding using a filter on which you
match traffic using source-class ussage ?

I want to forward traffic matching  particular source-class to a specific
routing-instance.

It seems that these 2 features do not work toghether according to:
http://www.juniper.net/techpubs/software/junos/junos72/swconfig72-policy/html/firewall-config33.html

The topology looks like this

R1-R2Customer router 1
|
|
Customer router 2


R1 and R2 are both ISP routers, R2 is the router on which I configure FBF
and SCU/DCU.

I want the metro traffic matched by community metro to be forwarded to
Customer router 2 IP address and all other traffic to be forwarded 
normaly.


R2 has EBGP session with Customer router 1.

THe FBF filter should be configured inbound on the link R1-R2 on R2.

Configuration

routing-instances {
   INSTANCE {
   instance-type forwarding;
   routing-options {
   static {
   route 0.0.0.0/0 nexthop Customer router 2 ;
   }

routing-options {
   forwarding-table {
   export SCU_DCU

}
   interface-routes {
   rib-group inet RIB_GROUP;
   }
   rib-groups {
   RIB_GROUP {
   import-rib [ inet.0 INSTANCE.inet.0 ];
   }
   }


protocols {
   bgp {
   group R2-CUSTOMER1  {
   type external;


   }
   }
   neighbor   Customer router 1 {
   peer-as1 ;

 community PEER members  2:1;
   community METRO members 2:2;
   community NATIONAL members 2:3;

policy-statement SCU_DCU {
   term  PEER {
   from {
   protocol bgp;
   community PEER;
   }
   then {
   destination-class DCU-PEER;
   source-class SCU-PEER;
   next policy;
   }
   }
   term METRO {
   from {
   protocol bgp;
   community METRO;
   }
   then {
   destination-class DCU-METRO;
   source-class SCU-METRO;
   next policy;
   }
   }
   term NATIONAL {
   from {
   protocol bgp;
   community NATIONAL;
   }
   then {
   destination-class DCU-NATIONAL;
   source-class SCU-NATIONAL;
   next policy;
   }
   }

   }
   }
   term REMAINING {
   then {
   destination-class DCU-REMAINING;
   source-class SCU-REMAINING;
   next policy;
   }

filter CUSTOMER_SCU {
   term CUSTOMER-SCU-INTERNATIONAL {
   from {
   source-class SCU-REMAINING;
   }
   then {
   policer  SCU-INTERNATIONAL;
   routing-instance INSTANCE;

   accept;

 term 2 then accept

CUSTOMER_SCU filter is applied outbound on the interface between R2 and
Custmer-router 1.


On the interface between R1 and R2 on R2 I apply :

family inet {
   accounting {
   source-class-usage {
   input;

Any alternative if this solution does not work?
How to forward traffic on differnet next-hops by matching communities/as
path/scu/dcu ?


Thank you,
Ioan
___
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] Filter based forwarding on Olive

[Ioan Branet]

Hello,

I used another filter applied to the interfaces which denies anything and it
seems that the filter is not working when applied to em1.0 interface.

Do you know what could be the cause?


r...@r1 show configuration interfaces em1.0
family inet {
filter {
input DENY_ALL;
}
address 150.1.13.1/24;
}
family mpls;
r...@r1 show configuration firewall filter DENY_ALL
term 1 {
then {
reject;
}
}


r...@r3 ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=64 time=0.498 ms
^C
--- 1.1.1.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.498/0.498/0.498/0.000 ms

r...@r3 ping 150.1.15.1
PING 150.1.15.1 (150.1.15.1): 56 data bytes
64 bytes from 150.1.15.1: icmp_seq=0 ttl=64 time=0.780 ms
^C
--- 150.1.15.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.780/0.780/0.780/0.000 ms

r...@r3 traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 40 byte packets
 1  1.1.1.1 (1.1.1.1)  1.341 ms  0.771 ms  0.073 ms


r...@r3 show route forwarding-table destination 1.1.1.1
Routing table: default.inet
Internet:
DestinationType RtRef Next hop   Type Index NhRef Netif
1.1.1.1/32 user 1 150.1.13.1 ucst   55410 em1.0

r...@r3 show configuration interfaces em1.0
family inet {
address 150.1.13.3/24;
}
family mpls;

r...@r3 show ospfne
  ^
syntax error, expecting command.
r...@r3 show ospf neighbor
Address  Interface  State ID   Pri  Dead
150.1.13.1   em1.0  Full  1.1.1.1  12839


Olive relevant  file :

ethernet1.present = TRUE
ethernet1.connectionType = custom
ethernet1.vnet = /dev/vmnet8
ethernet1.virtualDev = e1000

ethernet1.addressType = generated
ethernet1.pciSlotNumber = 34
ethernet1.generatedAddress = 00:0c:29:5a:3f:c1
ethernet1.generatedAddressOffset = 10

ethernet2.present = TRUE
ethernet2.connectionType = custom
ethernet2.vnet = /dev/vmnet2
ethernet2.virtualDev = e1000

ethernet2.addressType = generated
ethernet2.pciSlotNumber = 35
ethernet2.generatedAddress = 00:0c:29:5a:3f:cb
ethernet2.generatedAddressOffset = 20


On Tue, Sep 15, 2009 at 11:10 AM, Ioan Branet ioan.bra...@gmail.com wrote:

 Hello Group,

 I want to test the feature on Olive and it seems that is not ok.When I try
 to ping R5 loopback from R3 I receive icmp unreachable from R1 where the
 filter is applied.

 It seems that the filter is seen as unknown when applied to em1.0 interface
 on input.

 If you have a working example with instance type forwarding or instance
 type virtual router used with FBF it will help.



 My topology looks like this:

 R3 em0.0R1---em2.0---R5

 My configuration looks like this:

 r...@r1 show configuration firewall filter FBF
 term 1 {
 then {
 routing-instance FBF;
 }
 }

 r...@r1 show configuration routing-instances FBF
 instance-type forwarding;
 routing-options {
 static {
 route 0.0.0.0/0 next-hop 150.1.15.5;
 }
 }

 r...@r1 show configuration routing-options
 interface-routes {
 rib-group inet FBF;
 }
 rib-groups {
 FBF {
 import-rib [ inet.0 FBF.inet.0 ];
 }

 r...@r1 show configuration interfaces
 em0 {
 unit 0 {
 family inet {
 address 150.1.12.1/24;
 }
 family mpls;
 }
 }
 em1 {
 unit 0 {
 family inet {
 filter {
 input FBF;
 }
 address 150.1.13.1/24;
 }
 family mpls;
 }
 }
 em2 {
 unit 0 {
 family inet {
 address 150.1.15.1/24;
 }
 family mpls;
 }
 }
 lo0 {
 unit 0 {
 family inet {
 address 1.1.1.1/32;
 }
 }
 }

 r...@r3 show route 0.0.0.0

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

 0.0.0.0/0  *[Static/5] 03:08:35
  to 150.1.13.1 via em1.0

 r...@r3

 r...@r1 show route 0.0.0.0

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

 0.0.0.0/0  *[Static/5] 00:03:10
  to 150.1.15.5 via em2.0

 r...@r1 show route 5.5.5.5

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

 0.0.0.0/0  *[Static/5] 00:03:16
  to 150.1.15.5 via em2.0


 r...@r1 show route forwarding-table destination 0.0.0.0
 Routing table: default.inet
 Internet:
 DestinationType RtRef Next hop   Type Index NhRef Netif
 0.0.0.0/32 perm 0dscd34 1

 Routing table: __juniper_private1__.inet
 Internet:
 DestinationType RtRef Next hop   Type Index NhRef Netif
 0.0.0.0/32 perm 0  

Re: [j-nsp] Filter based forwarding on Olive

[Stefan Fouant]

Comments in-line...

On Tue, Sep 15, 2009 at 4:10 AM, Ioan Branet ioan.bra...@gmail.com wrote:

 Hello Group,

 I want to test the feature on Olive and it seems that is not ok.When I try
 to ping R5 loopback from R3 I receive icmp unreachable from R1 where the
 filter is applied.

 It seems that the filter is seen as unknown when applied to em1.0 interface
 on input.

 If you have a working example with instance type forwarding or instance
 type
 virtual router used with FBF it will help.



 My topology looks like this:

 R3 em0.0R1---em2.0---R5


In the diagram above I'm assuming you mean em1.0, not em0.0?  Because you
applied the ingress firewall filter to em1.0.


 My configuration looks like this:

 r...@r1 show configuration firewall filter FBF
 term 1 {
then {
routing-instance FBF;
}
 }

 r...@r1 show configuration routing-instances FBF
 instance-type forwarding;
 routing-options {
static {
route 0.0.0.0/0 next-hop 150.1.15.5;
}
 }

 r...@r1 show configuration routing-options
 interface-routes {
rib-group inet FBF;
 }
 rib-groups {
FBF {
import-rib [ inet.0 FBF.inet.0 ];
}

 r...@r1 show configuration interfaces
 em0 {
unit 0 {
family inet {
address 150.1.12.1/24;
}
family mpls;
}
 }
 em1 {
unit 0 {
family inet {
filter {
input FBF;
}
address 150.1.13.1/24;
}
family mpls;
}
 }
 em2 {
unit 0 {
family inet {
address 150.1.15.1/24;
}
family mpls;
}
 }
 lo0 {
unit 0 {
family inet {
address 1.1.1.1/32;
}
}
 }

 r...@r3 show route 0.0.0.0

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

 0.0.0.0/0  *[Static/5] 03:08:35
 to 150.1.13.1 via em1.0

 r...@r3

 r...@r1 show route 0.0.0.0

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

 0.0.0.0/0  *[Static/5] 00:03:10
 to 150.1.15.5 via em2.0

 r...@r1 show route 5.5.5.5

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

 0.0.0.0/0  *[Static/5] 00:03:16
 to 150.1.15.5 via em2.0


 r...@r1 show route forwarding-table destination 0.0.0.0
 Routing table: default.inet
 Internet:
 DestinationType RtRef Next hop   Type Index NhRef Netif
 0.0.0.0/32 perm 0dscd34 1

 Routing table: __juniper_private1__.inet
 Internet:
 DestinationType RtRef Next hop   Type Index NhRef Netif
 0.0.0.0/32 perm 0dscd   114 1

 Routing table: __juniper_private2__.inet
 Internet:
 DestinationType RtRef Next hop   Type Index NhRef Netif
 0.0.0.0/32 perm 0dscd   194 1

 Routing table: FBF.inet
 Internet:
 DestinationType RtRef Next hop   Type Index NhRef Netif
 0.0.0.0/32 perm 0dscd   529 1

 r...@r1

 r...@r1 show interfaces filters em1.0
 Interface   Admin Link Proto Input Filter Output Filter
 em1.0   upup   inet  unknown
   mpls

 r...@r3 traceroute 5.5.5.5
 traceroute to 5.5.5.5 (5.5.5.5), 30 hops max, 40 byte packets
  1  150.1.13.1 (150.1.13.1)  0.881 ms  0.671 ms  0.128 ms
  2  150.1.13.1 (150.1.13.1)  0.483 ms !H  0.694 ms !H  0.098 ms !H

 r...@r3 ping 5.5.5.5 source 150.1.13.3
 PING 5.5.5.5 (5.5.5.5): 56 data bytes
 36 bytes from 150.1.13.1: Destination Host Unreachable
 Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
  4  5  00 0054 6a0f   0   40  01 638c 150.1.13.3  5.5.5.5

 36 bytes from 150.1.13.1: Destination Host Unreachable
 Vr HL TOS  Len   ID Flg  off TTL Pro  cks  Src  Dst
  4  5  00 0054 6a10   0   40  01 638b 150.1.13.3  5.5.5.5

 ^C
 --- 5.5.5.5 ping statistics ---
 2 packets transmitted, 0 packets received, 100% packet loss


 r...@r1 ping routing-instance FBF 5.5.5.5 source 150.1.15.1
 PING 5.5.5.5 (5.5.5.5): 56 data bytes
 ping: sendto: Can't assign requested address
 ping: sendto: Can't assign requested address
 ping: sendto: Can't assign requested address
 ping: sendto: Can't assign requested address
 ^C


150.1.15.1 is associated with your em2.0 interface which is not bound to the
FBF routing-instance, therefore you can't specify it as the source of the
packet when sourcing pings from the FBF routing-instance,


 --- 5.5.5.5 ping statistics ---
 4 packets transmitted, 0 packets received, 100% packet loss

 r...@r1

 r...@r1 show route forwarding-table destination 5.5.5.5
 Routing table: default.inet
 Internet:
 DestinationType RtRef Next hop   Type Index NhRef Netif
 defaultperm 0

Re: [j-nsp] filter-based forwarding

[Paul Goyette]

Looks obvious - there's always a default term at the end
of a firewall filter to reject anything that gets that
far.

So try adding a 3rd term:

     filter classify-customers {
     term isp1-customers {
     from {
     source-address {
     10.1.1.0/24;
     }
     }
     then {
     routing-instance instance-1;
     }
     }
     term isp2-customers {
     from {
     source-address 
     {10.2.1.0/24;
     }
     then {
     routing-instance instance-2;
     }
     }

  term everything-else {
  then accept;
  }

     } *END of filter*
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] filter-based forwarding

[Paul Goyette]

 What I meant was the M120 stopped receiving routes(IGP) from 
 its upstream router;
  
 I've tried the term everything else thing but didn't work 
 out. Also tried this, didn't work either. Looks like the last 
 term has to use master routing instance.
  
 filter classify-customers {
 term isp1-customers {
 from {
 source-address {
 10.1.1.0/24;
 }
 }
 then {
 routing-instance instance-1;
 }
 }
 term isp2-customers {
 then {
 routing-instance instance-2;
 }
 }

I suspect it's a combination of:

1. Input filtering happens before determining that packets
   are locally addressed, and

2. The routing protocols are running in the default instance,
   with adjacencies formed on default-instance addressed.

So packets from your upstream will be diverted into the
alternate routing instance before we discover that those
packets have local destinations and therefore don't get
delivered to rpd.

You could confirm this hypothesis by checking your IGP to
see if you have any adjacencies.

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

Re: [j-nsp] Filter-based forwarding

[Stefan Fouant]

I can't really comment on any anomalies seen when using FBF as I
haven't seen any, but performance shouldn't be an issue due to the
Juniper packet forwarding architecture.  The IPII processor was
designed to make route lookups, forwarding decisions, and firewall
filtering (amongst other features) at very high speeds and the
technology has been proven for quite some time now.  The notification
cells are going to the IPII Processor regardless of whether you've got
FBF enabled or not, therefore in theory, there really shouldn't be any
performance impact at all.  The reality is that under certain
scenarios there might be a very slight performance impact on smaller
packet sizes ( 128Byes), but that impact is mostly negligible.

There are numerous case-studies as well as independant lab tests which
confirm it as such and if you do a google search you should be able to
find ample information to confirm this.

HTHs.

Stefan Fouant
Principal Network Engineer
NeuStar, Inc. - http://www.neustar.biz
GPG Key ID: 0xB5E3803D

On Wed, Jun 25, 2008 at 9:02 AM, Boyd, Benjamin R
[EMAIL PROTECTED] wrote:
 All,

 I've been toying around in the lab with some implementations of
 filter-based forwarding
 (http://www.juniper.net/techpubs/software/junos/junos72/swconfig72-polic
 y/html/firewall-config33.html) and before I deployed it in production I
 would like to hear of the successes/failures the community has had with
 this.  Let me know if you've experienced any traffic slowdown, any
 anomalies, etc.

 Thanks,
 Ben


 ***

 The information contained in this message, including attachments, may contain
 privileged or confidential information that is intended to be delivered only 
 to the
 person identified above. If you are not the intended recipient, or the person
 responsible for delivering this message to the intended recipient, Windstream 
 requests
 that you immediately notify the sender and asks that you do not read the 
 message or its
 attachments, and that you delete them without copying or sending them to 
 anyone else.

 ___
 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] Filter-based forwarding

[Stefan Fouant]

After reading my previous post, I realize it was targeted towards M/T
Series architectures... the J-Series don't have the IPII but do have
the 'fwdd' daemon which is essentially a virtualize PFE (emulating the
ASICs and forwarding hardware which is normally found on the M/T
Series).  This process has been tuned to provide deterministic
performance comparable to that which you would see on the M/T Series
as well... so rest assured if you're planning to run FBF on a J-Series
there should be little performance impact.

Good luck,

Stefan Fouant
Principal Network Engineer
NeuStar, Inc. - http://www.neustar.biz
GPG Key ID: 0xB5E3803D

On Wed, Jun 25, 2008 at 10:22 AM, Stefan Fouant [EMAIL PROTECTED] wrote:
 I can't really comment on any anomalies seen when using FBF as I
 haven't seen any, but performance shouldn't be an issue due to the
 Juniper packet forwarding architecture.  The IPII processor was
 designed to make route lookups, forwarding decisions, and firewall
 filtering (amongst other features) at very high speeds and the
 technology has been proven for quite some time now.  The notification
 cells are going to the IPII Processor regardless of whether you've got
 FBF enabled or not, therefore in theory, there really shouldn't be any
 performance impact at all.  The reality is that under certain
 scenarios there might be a very slight performance impact on smaller
 packet sizes ( 128Byes), but that impact is mostly negligible.

 There are numerous case-studies as well as independant lab tests which
 confirm it as such and if you do a google search you should be able to
 find ample information to confirm this.

 HTHs.

 Stefan Fouant
 Principal Network Engineer
 NeuStar, Inc. - http://www.neustar.biz
 GPG Key ID: 0xB5E3803D

 On Wed, Jun 25, 2008 at 9:02 AM, Boyd, Benjamin R
 [EMAIL PROTECTED] wrote:
 All,

 I've been toying around in the lab with some implementations of
 filter-based forwarding
 (http://www.juniper.net/techpubs/software/junos/junos72/swconfig72-polic
 y/html/firewall-config33.html) and before I deployed it in production I
 would like to hear of the successes/failures the community has had with
 this.  Let me know if you've experienced any traffic slowdown, any
 anomalies, etc.

 Thanks,
 Ben


 ***

 The information contained in this message, including attachments, may contain
 privileged or confidential information that is intended to be delivered only 
 to the
 person identified above. If you are not the intended recipient, or the person
 responsible for delivering this message to the intended recipient, 
 Windstream requests
 that you immediately notify the sender and asks that you do not read the 
 message or its
 attachments, and that you delete them without copying or sending them to 
 anyone else.

 ___
 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] Filter-based forwarding

[Boyd, Benjamin R]

I'm planning on implementing it on an m-series.  I'm fairly certain
there won't be any problems, but it's always better to hear from the
community about any unforeseen problems first :)

-Ben 

-Original Message-
From: Stefan Fouant [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 25, 2008 9:36 AM
To: Boyd, Benjamin R
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Filter-based forwarding

After reading my previous post, I realize it was targeted towards M/T
Series architectures... the J-Series don't have the IPII but do have the
'fwdd' daemon which is essentially a virtualize PFE (emulating the ASICs
and forwarding hardware which is normally found on the M/T Series).
This process has been tuned to provide deterministic performance
comparable to that which you would see on the M/T Series as well... so
rest assured if you're planning to run FBF on a J-Series there should be
little performance impact.

Good luck,

Stefan Fouant
Principal Network Engineer
NeuStar, Inc. - http://www.neustar.biz
GPG Key ID: 0xB5E3803D

On Wed, Jun 25, 2008 at 10:22 AM, Stefan Fouant [EMAIL PROTECTED]
wrote:
 I can't really comment on any anomalies seen when using FBF as I 
 haven't seen any, but performance shouldn't be an issue due to the 
 Juniper packet forwarding architecture.  The IPII processor was 
 designed to make route lookups, forwarding decisions, and firewall 
 filtering (amongst other features) at very high speeds and the 
 technology has been proven for quite some time now.  The notification 
 cells are going to the IPII Processor regardless of whether you've got

 FBF enabled or not, therefore in theory, there really shouldn't be any

 performance impact at all.  The reality is that under certain 
 scenarios there might be a very slight performance impact on smaller 
 packet sizes ( 128Byes), but that impact is mostly negligible.

 There are numerous case-studies as well as independant lab tests which

 confirm it as such and if you do a google search you should be able to

 find ample information to confirm this.

 HTHs.

 Stefan Fouant
 Principal Network Engineer
 NeuStar, Inc. - http://www.neustar.biz GPG Key ID: 0xB5E3803D

 On Wed, Jun 25, 2008 at 9:02 AM, Boyd, Benjamin R 
 [EMAIL PROTECTED] wrote:
 All,

 I've been toying around in the lab with some implementations of 
 filter-based forwarding 
 (http://www.juniper.net/techpubs/software/junos/junos72/swconfig72-po
 lic
 y/html/firewall-config33.html) and before I deployed it in production

 I would like to hear of the successes/failures the community has had 
 with this.  Let me know if you've experienced any traffic slowdown, 
 any anomalies, etc.

 Thanks,
 Ben


 *
 **

 The information contained in this message, including attachments, may

 contain privileged or confidential information that is intended to be

 delivered only to the person identified above. If you are not the 
 intended recipient, or the person responsible for delivering this 
 message to the intended recipient, Windstream requests that you 
 immediately notify the sender and asks that you do not read the
message or its attachments, and that you delete them without copying or
sending them to anyone else.

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





***

The information contained in this message, including attachments, may contain 
privileged or confidential information that is intended to be delivered only to 
the 
person identified above. If you are not the intended recipient, or the person 
responsible for delivering this message to the intended recipient, Windstream 
requests 
that you immediately notify the sender and asks that you do not read the 
message or its 
attachments, and that you delete them without copying or sending them to anyone 
else.

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

Re: [j-nsp] Filter-Based Forwarding issue

[Jared Gull]

Could you provide the configuration snippets for the
routing-options, routing-instances, and a 'show route
summary' output.

--- Gniewko [EMAIL PROTECTED] wrote:

 Hello There,
 
 I've exprienced weird behaviour of FBF - it doesn't
 work at all :).
 Suppose there is a very simple filter:
 
 # show firewall family inet filter
 FILTER_INSTANCE_TO
 
 term C {
 from {
 source-prefix-list {
 PLIST_C;
 }
 }
 then {
 count ccount;
 routing-instance INSTANCE_C;
 }
 }
 
 term D {
 from {
 source-prefix-list {
 PLIST_D;
 }
 }
 then {
 count dcount;
 routing-instance INSTANCE_D;
 }
 }
 
 term DEFAULT {
 then {
 count defaultcount;
 accept;
 }
 }
 
 
 # show interfaces ge-1/3/0 unit 24
 vlan-id 24;
 family inet {
 no-redirects;
 filter {
 input FILTER_INSTANCE_TO;
 }
 
 
 # run show firewall filter FILTER_INSTANCE_TO
 Filter: FILTER_INSTANCE_TO
 Counters:
 Name   
 Bytes
 Packets
 defaultcount
0
 0
 ccount  
  0
 0
 dcount  
  0
 0
 
 Everything is routed based on inet.0 only, but it's
 not becaue of the
 filter ('defaultcount' counter value). PLIST_C and
 PLIST_D are fine,
 cause are being used many times in other statements.
 
 Perhaps there is something obvious what i'm missing,
 so would be more
 than thankful for any hint.
 
 TIA,
 
 -- 
 Gniewko
 
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp
 



 

Bored stiff? Loosen up... 
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp