[j-nsp] Best way to use transparent caching with M/E-series

[Ebben Aries]

RPM is great for monitoring performance and pulling via SNMP or NETCONF but I don't believe you can have the rpm trigger an action based on a threshold which is what you are attempting to accomplish.

-- 
ebb

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Alex
Sent: Wednesday, June 14, 2006 10:14 AM
To: Guy Davies; Dean Albano
Cc: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Best way to use transparent caching with M/E-series

RPM (Real Time Performance Monitoring) is able to send HTTP probes (I think 
these are GETs).
HTH
Cheers
Alex

----- Original Message ----- 
From: "Guy Davies" <aguydavies at gmail.com>
To: "Dean Albano" <dean.albano at 121media.com>
Cc: <juniper-nsp at puck.nether.net>
Sent: Wednesday, June 14, 2006 2:26 PM
Subject: Re: [j-nsp] Best way to use transparent caching with M/E-series


Hi Dean,

There's no "http checker" or the like.  I suppose if the cache device
is *directly connected* to the router and the interface goes down,
then you could have a second, less preferred default route in the
cache routing-instance that points to the same place as the default
route in the inet.0 routing table.  But that would rely on the
interface on the router recognising that it was down so the router no
longer had a path to 192.168.2.2 (in my example).  That would make
that static route unusable and the less preferred static would be
used.

I haven't tested that so treat with due scepticism ;-)

Rgds,

Guy

On 14/06/06, Dean Albano <dean.albano at 121media.com> wrote:
> Thanks Guy.  We will give this a try.  One question though; what
> happens if the cache host goes down?  Is there any mechanism with
> Filter Based Forwarding to identify that the cache host is down and
> route http traffic around it?
>
> Regards,
>
> Dean J. Albano
> Network Integration Consultant
>
>
> On Jun 14, 2006, at 8:37 AM, Guy Davies wrote:
>
> Hi Dean,
>
> You can do something similar on the M/T series by doing filter based
> forwarding.
>
> You need a minimum of three interfaces.
>
> 1. The ingress interface from which http/https requests will be
> received.
> 2. The egress interface to the Internet
> 3. The egress interface to the Caching device
>
> You identify ingress traffic that is http or https and then apply a
> non-standard routing-instance (with a default pointing to the Caching
> device) to that traffic.  The traffic is then forwarded to the caching
> device which is able to either respond direct or has to make a query
> to the Internet.  It is important to apply the filter to the input of
> the ingress interface rather than the output of the egress to the
> Internet or you'll catch the traffic from the caching device too and
> send it back to the caching device.
>
> interfaces {
>    ge-0/0/0 {
>       description "Ingress";
>       family inet {
>           address 192.168.0.1/24;
>           filter {
>              input transparent-cache;
>          }
>       }
>     }
>     ge-0/1/0 {
>         description "Egress";
>         family inet {
>             address 192.168.1.1/24;
>         }
>     }
>     ge-0/2/0 {
>         description "Cache";
>         family inet {
>             address 192.168.2.1/24;
>         }
>     }
> }
> firewall {
>     family inet {
>         filter transparent-cache {
>            term http-https {
>                from {
>                    protocol tcp;
>                    destination-port [ 80 443 ];
>                }
>                then {
>                    routing-instance cache;
>                }
>             }
>             term default {
>                 then accept;
>             }
>         }
>     }
> }
> routing-instances {
>     cache {
>         instance-type forwarding;
>         routing-options {
>             static {
>                 route 0.0.0.0/0 next-hop 192.168.2.2;
>             }
>         }
>     }
> }
> routing-options {
>     interface-routes {
>         rib-group inet direct-if;
>     }
>     rib-groups {
>         direct-if {
>             import-rib [ inet.0 cache.inet.0 ];
>         }
>     }
> }
>
> Rgds,
>
> Guy
>
> On 14/06/06, Bjørn Mork <bjorn at mork.no> wrote:
> > Dean Albano <dean.albano at 121media.com> writes:
> >
> > > What would be the best way to do transparent caching through either
> > > an M-series or E-series router?
> >
> > Put a L4-switch at either side of it?
> >
> >
> > Bjørn
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > http://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
>

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp 

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp