Mailing List Archive

Traffic sourced from the RE (Routing Engine) is sent via the control
plain on an internal FastEthernet connection to the PFE (Packet
Forwarding Engine - Internet Processor) and then forwarded via the
forwarding plane.

Running ping tests from the the RE (Routing Engine) will not disturb
the other control traffic as this is prioritized and limited. Routing
control traffic etc takes precedence over ICPM ping traffic sourced
from the RE.

There are queues and limiting of traffic types between the RE and the
PFE in both directions to protect the RE from being overrun by traffic
in the event of DOS attacks etc.

Additional filters and policers can be added between the RE and the PFE
to further protect the system.

There is a publicly available document about security which has a
section detailing "Applying Firewall Filers to the Routing Engine" as
well as other useful security advise at the following location:

http://www.juniper.net/solutions/literature/app_note/350013.pdf

Additional information can be obtained through the Juniper JTAC.
Thanks
Gary

On Dec 9, 2003, at 5:56 AM, mark@glassbil.net wrote:

> Hi,
>
> Still rather new to Juniper and only have a basic knowledge
> over how it works. But i have heard that when im doing massive
> ping test from a Juniper i could disturb "live" traffic. I can?t
> really find a simple answer to what or how this is.
>
> Question:
> Could a massive ping test from a Juniper (M160 in this case) cause
> disturbance in the orignal traffic flow / processes in a M160?
>
> Say you have 4 sessions and running 4 x rapid ping with 5000 bytes.
> Could this overload the RE? Or the bus?
>
> Thanx for any replys.
>
> //Mark
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>

hmm So,

What are the Default filters? If i remember I saw something on this
list saying 50pps on an m20 with SSB-E to the RE, yet this security doc
is limiting to 500kpps.. that doesnt make sense. Wont the built-in
filter take over first? Also when is this filter applied? Only to
packets destined to the lo address or any icmp to any interface with a
real ip?

I'm asking cause Im seeing alot of throttled icmps..

scott@bdr1> show pfe statistics ip icmp
{snip}
ICMP Errors:
{snip}
0 bad input interface
6984689 throttled icmps
0 runts

What condition causes throttled icmps?

-Scotty

On Tue, 2003-12-09 at 10:28, Gary Tate wrote:
> Traffic sourced from the RE (Routing Engine) is sent via the control
> plain on an internal FastEthernet connection to the PFE (Packet
> Forwarding Engine - Internet Processor) and then forwarded via the
> forwarding plane.
>
> Running ping tests from the the RE (Routing Engine) will not disturb
> the other control traffic as this is prioritized and limited. Routing
> control traffic etc takes precedence over ICPM ping traffic sourced
> from the RE.
>
> There are queues and limiting of traffic types between the RE and the
> PFE in both directions to protect the RE from being overrun by traffic
> in the event of DOS attacks etc.
>
> Additional filters and policers can be added between the RE and the PFE
> to further protect the system.
>
> There is a publicly available document about security which has a
> section detailing "Applying Firewall Filers to the Routing Engine" as
> well as other useful security advise at the following location:
>
> http://www.juniper.net/solutions/literature/app_note/350013.pdf
>
> Additional information can be obtained through the Juniper JTAC.
> Thanks
> Gary
>
> On Dec 9, 2003, at 5:56 AM, mark@glassbil.net wrote:
>
> > Hi,
> >
> > Still rather new to Juniper and only have a basic knowledge
> > over how it works. But i have heard that when im doing massive
> > ping test from a Juniper i could disturb "live" traffic. I can?t
> > really find a simple answer to what or how this is.
> >
> > Question:
> > Could a massive ping test from a Juniper (M160 in this case) cause
> > disturbance in the orignal traffic flow / processes in a M160?
> >
> > Say you have 4 sessions and running 4 x rapid ping with 5000 bytes.
> > Could this overload the RE? Or the bus?
> >
> > Thanx for any replys.
> >
> > //Mark
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > http://puck.nether.net/mailman/listinfo/juniper-nsp
> >
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
>

Ok,

This was what i have been told.

But doens?t every "ping" from a Juniper cause a CPU interrupt? And this
will force it to respond and hence occupy cpu time? So in theory you could
disturb the Juniper (depending on CPU load) if you generate to mutch
traffic troght the RE/CPU or is this controlled by limiting the process of
ICMP?

My worry is that if several people is logged in to the M160 doing massive
ping tests at the same time it will cause problems with the Juniper.

Best Regards
Mark



> Traffic sourced from the RE (Routing Engine) is sent via the control
> plain on an internal FastEthernet connection to the PFE (Packet
> Forwarding Engine - Internet Processor) and then forwarded via the
> forwarding plane.
>
> Running ping tests from the the RE (Routing Engine) will not disturb
> the other control traffic as this is prioritized and limited. Routing
> control traffic etc takes precedence over ICPM ping traffic sourced
> from the RE.
>
> There are queues and limiting of traffic types between the RE and the
> PFE in both directions to protect the RE from being overrun by traffic
> in the event of DOS attacks etc.
>
> Additional filters and policers can be added between the RE and the PFE
> to further protect the system.
>
> There is a publicly available document about security which has a
> section detailing "Applying Firewall Filers to the Routing Engine" as
> well as other useful security advise at the following location:
>
> http://www.juniper.net/solutions/literature/app_note/350013.pdf
>
> Additional information can be obtained through the Juniper JTAC.
> Thanks
> Gary
>
> On Dec 9, 2003, at 5:56 AM, mark@glassbil.net wrote:
>
>> Hi,
>>
>> Still rather new to Juniper and only have a basic knowledge
>> over how it works. But i have heard that when im doing massive
>> ping test from a Juniper i could disturb "live" traffic. I can?t
>> really find a simple answer to what or how this is.
>>
>> Question:
>> Could a massive ping test from a Juniper (M160 in this case) cause
>> disturbance in the orignal traffic flow / processes in a M160?
>>
>> Say you have 4 sessions and running 4 x rapid ping with 5000 bytes.
>> Could this overload the RE? Or the bus?
>>
>> Thanx for any replys.
>>
>> //Mark
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
>

On Tue, Dec 09, 2003 at 10:50:49AM -0500, Scotty wrote:
> hmm So,
>
> What are the Default filters? If i remember I saw something on this
> list saying 50pps on an m20 with SSB-E to the RE, yet this security doc
> is limiting to 500kpps.. that doesnt make sense. Wont the built-in
> filter take over first? Also when is this filter applied? Only to
> packets destined to the lo address or any icmp to any interface with a
> real ip?
>
> I'm asking cause Im seeing alot of throttled icmps..
>
> scott@bdr1> show pfe statistics ip icmp
> {snip}
> ICMP Errors:
> {snip}
> 0 bad input interface
> 6984689 throttled icmps
> 0 runts
>
> What condition causes throttled icmps?

PFE statistics are not related to the RE. Those are ICMPs being generated
by the exception processor on the SSB, such as dest unreachables and ttl
exceeds for traceroute responses.

Ex:

ICMP Statistics:
75516902 requests
6037257 network unreachables
40493136 ttl expired
...
28970412 throttled icmps

--
Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Scotty

The document mentions 500 Kbps not Kpps for ICMP and TCP Syn attacks.
I will check on the throttled ICMPs but I believe this is due to the
topic under discussion here

Gary

On Dec 9, 2003, at 7:50 AM, Scotty wrote:

> hmm So,
>
> What are the Default filters? If i remember I saw something on this
> list saying 50pps on an m20 with SSB-E to the RE, yet this security doc
> is limiting to 500kpps.. that doesnt make sense. Wont the built-in
> filter take over first? Also when is this filter applied? Only to
> packets destined to the lo address or any icmp to any interface with a
> real ip?
>
> I'm asking cause Im seeing alot of throttled icmps..
>
> scott@bdr1> show pfe statistics ip icmp
> {snip}
> ICMP Errors:
> {snip}
> 0 bad input interface
> 6984689 throttled icmps
> 0 runts
>
> What condition causes throttled icmps?
>
> -Scotty
>
> On Tue, 2003-12-09 at 10:28, Gary Tate wrote:
>> Traffic sourced from the RE (Routing Engine) is sent via the control
>> plain on an internal FastEthernet connection to the PFE (Packet
>> Forwarding Engine - Internet Processor) and then forwarded via the
>> forwarding plane.
>>
>> Running ping tests from the the RE (Routing Engine) will not disturb
>> the other control traffic as this is prioritized and limited. Routing
>> control traffic etc takes precedence over ICPM ping traffic sourced
>> from the RE.
>>
>> There are queues and limiting of traffic types between the RE and the
>> PFE in both directions to protect the RE from being overrun by traffic
>> in the event of DOS attacks etc.
>>
>> Additional filters and policers can be added between the RE and the
>> PFE
>> to further protect the system.
>>
>> There is a publicly available document about security which has a
>> section detailing "Applying Firewall Filers to the Routing Engine" as
>> well as other useful security advise at the following location:
>>
>> http://www.juniper.net/solutions/literature/app_note/350013.pdf
>>
>> Additional information can be obtained through the Juniper JTAC.
>> Thanks
>> Gary
>>
>> On Dec 9, 2003, at 5:56 AM, mark@glassbil.net wrote:
>>
>>> Hi,
>>>
>>> Still rather new to Juniper and only have a basic knowledge
>>> over how it works. But i have heard that when im doing massive
>>> ping test from a Juniper i could disturb "live" traffic. I can?t
>>> really find a simple answer to what or how this is.
>>>
>>> Question:
>>> Could a massive ping test from a Juniper (M160 in this case) cause
>>> disturbance in the orignal traffic flow / processes in a M160?
>>>
>>> Say you have 4 sessions and running 4 x rapid ping with 5000 bytes.
>>> Could this overload the RE? Or the bus?
>>>
>>> Thanx for any replys.
>>>
>>> //Mark
>>>
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> http://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>

On Dec 9, 2003, at 8:24 AM, mark@glassbil.net wrote:

> Ok,
>
> This was what i have been told.
>
> But doens?t every "ping" from a Juniper cause a CPU interrupt? And this
> will force it to respond and hence occupy cpu time? So in theory you
> could
> disturb the Juniper (depending on CPU load) if you generate to mutch
> traffic troght the RE/CPU or is this controlled by limiting the
> process of
> ICMP?
>
Indeed this will cause some CPU time usage but very small. Processes on
the RE are tightly controlled and ping will not overrun any essential
processes on the CPU.

> My worry is that if several people is logged in to the M160 doing
> massive
> ping tests at the same time it will cause problems with the Juniper.
>
This will not cause a problem.
Pings are limited to 50 pps and the ping process takes very little CPU.

> Best Regards
> Mark
>
>
>
>> Traffic sourced from the RE (Routing Engine) is sent via the control
>> plain on an internal FastEthernet connection to the PFE (Packet
>> Forwarding Engine - Internet Processor) and then forwarded via the
>> forwarding plane.
>>
>> Running ping tests from the the RE (Routing Engine) will not disturb
>> the other control traffic as this is prioritized and limited. Routing
>> control traffic etc takes precedence over ICPM ping traffic sourced
>> from the RE.
>>
>> There are queues and limiting of traffic types between the RE and the
>> PFE in both directions to protect the RE from being overrun by traffic
>> in the event of DOS attacks etc.
>>
>> Additional filters and policers can be added between the RE and the
>> PFE
>> to further protect the system.
>>
>> There is a publicly available document about security which has a
>> section detailing "Applying Firewall Filers to the Routing Engine" as
>> well as other useful security advise at the following location:
>>
>> http://www.juniper.net/solutions/literature/app_note/350013.pdf
>>
>> Additional information can be obtained through the Juniper JTAC.
>> Thanks
>> Gary
>>
>> On Dec 9, 2003, at 5:56 AM, mark@glassbil.net wrote:
>>
>>> Hi,
>>>
>>> Still rather new to Juniper and only have a basic knowledge
>>> over how it works. But i have heard that when im doing massive
>>> ping test from a Juniper i could disturb "live" traffic. I can?t
>>> really find a simple answer to what or how this is.
>>>
>>> Question:
>>> Could a massive ping test from a Juniper (M160 in this case) cause
>>> disturbance in the orignal traffic flow / processes in a M160?
>>>
>>> Say you have 4 sessions and running 4 x rapid ping with 5000 bytes.
>>> Could this overload the RE? Or the bus?
>>>
>>> Thanx for any replys.
>>>
>>> //Mark
>>>
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> http://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>
>>
>

Scott

These are local PFE statistics and 'throttled icmps' shows rate
limiting of ICMPs that would be handled locally. They are throttled to
50pps

Gary

On Dec 9, 2003, at 8:39 AM, Gary Tate wrote:

> Scotty
>
> The document mentions 500 Kbps not Kpps for ICMP and TCP Syn attacks.
> I will check on the throttled ICMPs but I believe this is due to the
> topic under discussion here
>
> Gary
>
> On Dec 9, 2003, at 7:50 AM, Scotty wrote:
>
>> hmm So,
>>
>> What are the Default filters? If i remember I saw something on this
>> list saying 50pps on an m20 with SSB-E to the RE, yet this security
>> doc
>> is limiting to 500kpps.. that doesnt make sense. Wont the built-in
>> filter take over first? Also when is this filter applied? Only to
>> packets destined to the lo address or any icmp to any interface with a
>> real ip?
>>
>> I'm asking cause Im seeing alot of throttled icmps..
>>
>> scott@bdr1> show pfe statistics ip icmp
>> {snip}
>> ICMP Errors:
>> {snip}
>> 0 bad input interface
>> 6984689 throttled icmps
>> 0 runts
>>
>> What condition causes throttled icmps?
>>
>> -Scotty
>>
>> On Tue, 2003-12-09 at 10:28, Gary Tate wrote:
>>> Traffic sourced from the RE (Routing Engine) is sent via the control
>>> plain on an internal FastEthernet connection to the PFE (Packet
>>> Forwarding Engine - Internet Processor) and then forwarded via the
>>> forwarding plane.
>>>
>>> Running ping tests from the the RE (Routing Engine) will not disturb
>>> the other control traffic as this is prioritized and limited.
>>> Routing
>>> control traffic etc takes precedence over ICPM ping traffic sourced
>>> from the RE.
>>>
>>> There are queues and limiting of traffic types between the RE and
>>> the
>>> PFE in both directions to protect the RE from being overrun by
>>> traffic
>>> in the event of DOS attacks etc.
>>>
>>> Additional filters and policers can be added between the RE and the
>>> PFE
>>> to further protect the system.
>>>
>>> There is a publicly available document about security which has a
>>> section detailing "Applying Firewall Filers to the Routing Engine" as
>>> well as other useful security advise at the following location:
>>>
>>> http://www.juniper.net/solutions/literature/app_note/350013.pdf
>>>
>>> Additional information can be obtained through the Juniper JTAC.
>>> Thanks
>>> Gary
>>>
>>> On Dec 9, 2003, at 5:56 AM, mark@glassbil.net wrote:
>>>
>>>> Hi,
>>>>
>>>> Still rather new to Juniper and only have a basic knowledge
>>>> over how it works. But i have heard that when im doing massive
>>>> ping test from a Juniper i could disturb "live" traffic. I can?t
>>>> really find a simple answer to what or how this is.
>>>>
>>>> Question:
>>>> Could a massive ping test from a Juniper (M160 in this case) cause
>>>> disturbance in the orignal traffic flow / processes in a M160?
>>>>
>>>> Say you have 4 sessions and running 4 x rapid ping with 5000 bytes.
>>>> Could this overload the RE? Or the bus?
>>>>
>>>> Thanx for any replys.
>>>>
>>>> //Mark
>>>>
>>>> _______________________________________________
>>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>>> http://puck.nether.net/mailman/listinfo/juniper-nsp
>>>>
>>>
>>>
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> http://puck.nether.net/mailman/listinfo/juniper-nsp
>>>
>>
>

To be clear on this point:

Sourced from the RE pings are limited via queuing mechanisms on the
fxp1 connetion to the PFE
These packets have a lower priority than other control traffic and will
be dropped when necessary. It is advisable to limit them as per the
document I posted:

>>> http://www.juniper.net/solutions/literature/app_note/350013.pdf

As this will guard against incoming DOS attacks.

show pfe statistics ip icmp

This shows all icmp packet statistics for the PFE.

The pfe cpu complex limits icmp to 50pps per ifl and 500pps box wide

I hope this clears up any confusion

Gary

Almost done here ;-)

I think i have it figured out but still one question remains.
How will the b-chip handle the fragmentation during high load?

If you don?t ping with a size bigger then the MTU the packet
will only be proccesed by the CPU - re to linecard. But if you as i said
before add a paket size the b-chip will be used. Is the resources of the
b-chip also protected?

Best Regards
Mark

> To be clear on this point:
>
> Sourced from the RE pings are limited via queuing mechanisms on the
> fxp1 connetion to the PFE
> These packets have a lower priority than other control traffic and will
> be dropped when necessary. It is advisable to limit them as per the
> document I posted:
>
>>>> http://www.juniper.net/solutions/literature/app_note/350013.pdf
>
> As this will guard against incoming DOS attacks.
>
> show pfe statistics ip icmp
>
> This shows all icmp packet statistics for the PFE.
>
> The pfe cpu complex limits icmp to 50pps per ifl and 500pps box wide
>
> I hope this clears up any confusion
>
> Gary
>
>

The B-Chip is an ASIC which has channels which have bandwidth. Each
channel has queues that will limit bases on you CoS configuration.

As far as fragmentation goes the b-chip does not need protection from
the RE as you cannot ping enough traffic from the RE to cause the
b-chip any problems.

I am not an expert on the inner workings of the b-chip so you should
contact the JTAC if you have any further queries.

Gary

On Dec 10, 2003, at 6:56 AM, mark@glassbil.net wrote:

> Almost done here ;-)
>
> I think i have it figured out but still one question remains.
> How will the b-chip handle the fragmentation during high load?
>
> If you don?t ping with a size bigger then the MTU the packet
> will only be proccesed by the CPU - re to linecard. But if you as i
> said
> before add a paket size the b-chip will be used. Is the resources of
> the
> b-chip also protected?
>
> Best Regards
> Mark
>
>> To be clear on this point:
>>
>> Sourced from the RE pings are limited via queuing mechanisms on the
>> fxp1 connetion to the PFE
>> These packets have a lower priority than other control traffic and
>> will
>> be dropped when necessary. It is advisable to limit them as per the
>> document I posted:
>>
>>>>> http://www.juniper.net/solutions/literature/app_note/350013.pdf
>>
>> As this will guard against incoming DOS attacks.
>>
>> show pfe statistics ip icmp
>>
>> This shows all icmp packet statistics for the PFE.
>>
>> The pfe cpu complex limits icmp to 50pps per ifl and 500pps box wide
>>
>> I hope this clears up any confusion
>>
>> Gary
>>
>>
>