[j-nsp] About MIC-3D-40C30C 12-10C48 Configuration
Dear Honorable member: Wishes all are fine. I have MIC-3D-40C30C 12-10C48 PIC. i want to configuration one of the port of this PIC for STM4. For this reason , Can you any one inform the basic configuration of Sonet interface for STM4 in juniper MX router Thanks jahangir ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX3600 - Session Logs
Yup there is.
As the high end boxes do all the processing for the firewalling/VPN/IDP etc
on the SPCs, we can set the logs to be sent from teh SPC instead of being
passed across to the RE.
Basically a high end SRX can create more logs than the RE can handle so we
send logs via stream mode to the syslog/STRM box.
Basic config is below
mark@vodkila show configuration security log
mode stream;
format sd-syslog;
source-address 10.1.1.1;
stream securitylog {
category all;
host {
10.1.1.26;
port 514;
}
}
Where the host is the syslog server and the source-address is to ensure
that the traffic leaves from correct interface/routing-instance
On 1 December 2012 14:58, Giuliano Medalha giuli...@wztech.com.br wrote:
People,
Does anyone could set log information about sessions using SRX36xx boxes ?
Could you please send this information for me ?
We have tried to use the following syslog config:
user@host# *set system syslog file traffic-log any any*
user@host# *set system syslog file traffic-log match RT_FLOW_SESSION
But it is not working.
There is some special way to do it using high end boxex ?
Thanks a lot,
Giuliano
*
___
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] Routing Instance BGP Full Routing High Memory persists
This is actually expected behavior of Unix-like OSes in general. RPD may in fact have released the memory (using free()) but will still have that RAM associated with it. This is due to the fact that Unix (BSDlike esp) generally use brk() or sbrk() under the hood during malloc() to request more RAM from the OS. There's actually no way for a process to return memory to the OS. Recent versions of POSIX have removed brk/sbrk from the standard...but I believe at heart that libc/glibc still use this mechanism to extend their address space/request more RAM from the OS. brk() can in theory reduce this allocation but I do not believe free() attempts this, and the only thing brk() can do anyway is set the end of the address space, so unless your memory space is defragmented you may end up with memory used at the end of the space keeping everything allocated. Memory management under the hood gets really complicated obviously. In general on Unix-like OSes it's expected a processes memory utilization will grow to a peak, and then stay there. So the OS and it's interfaces are built around this (very reasonable, and in general very true) assumption. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] node-link-protection Interop
Hi Expert,
If on Juniper ( aggregation ) box we configure node-link protection. Then we
insert Cisco ( Core ) router. is there any issue? or do we need to change to
link-protection only for interoperability?
.
protocols {
mpls {
icmp-tunneling;
label-switched-path * {
ldp-tunneling;
least-fill;
node-link-protection;
adaptive;
}
interface xe-*;
interface ge-*;
}
}
Wan
(CCNA,CCSI, BIT Software Engineering)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Routing Instance BGP Full Routing High Memory persists
Michael Loftis mlof...@wgops.com writes: This is actually expected behavior of Unix-like OSes in general. RPD may in fact have released the memory (using free()) but will still have that RAM associated with it. This is due to the fact that Unix (BSDlike esp) generally use brk() or sbrk() under the hood during malloc() to request more RAM from the OS. There's actually no way for a process to return memory to the OS. I believe you are a few years out of date with that information. Modern malloc() implementations tend to use mmap() to get their memory, and free() tends to unmap memory if the malloc library does not expect to need the memory again soon. There is often a delay before the unmap. However, it is easy to end up with fragmented memory which cannot be returned to the OS. As long as there is even a single byte in use on a page, that page has to be kept around. The various malloc libraries vary in how good they are at avoiding fragmentation, but none of them are perfect. Most often it doesn't matter anyway; if a single almost-never-used byte keeps a page from being freed, it can just go to swap. Similarly, if an empty page is kept around just-in-case and the system needs the space, it can just go to swap. Routers, however, rarely have swap... /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX, UDP traffic, routing asymmetry
Hi all, I'm at the start of troubleshooting a strange problem we've experienced recently with voice signalling (UNIStim) traffic. Our WAN is based upon a carrier L3VPN but we build IPsec tunnels (st0.x) over the top and we do not have a full mesh. The end result is that traffic between branch sites needs to hair-pin on an intermediate device (a J or SRX box). Sometimes (due to OSPF's route selection process when presented with equal cost routes) the path traffic takes from A to B is not the same as the path from B to A -- the intermediate device to hair-pin on (for A-B and B-A) is different. In performance terms, the difference is insignificant. Most of the time the intermediate devices are sitting next to each other in a rack (e.g. primary and secondary routers). Does the SRX do something special with asymmetric UDP flows? When I say UDP I mean UDP generically, because I'm aware of special cases like set security flow allow-dns-reply. I have an ever-growing suspicion that we are throwing packets on the floor in certain circumstances. cheers, Dale (..on the never-ending quest to make SRXs behave like routers w/IPsec) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] export OSPF routes as type 1
I'm trying to export some OSPF routes as type 1 external instead of the default type 2 external. I can't seem to find where it is done - I thought it would be done in the policy map but I don't see an option. I know in Cisco you do it when you enter the redistribute command... thought it would be in a similar place on juniper but obviously not... Can't find much info online about this either... Any help would be great Thanks, Luca. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX, UDP traffic, routing asymmetry
SRX as router with IPsec? Have you tried Router Context? Most docs talk about J-series, but it works with SRX as well. If you need security (as in policies and zones) as well, there is selective packet mode. I have done some work in that area, and can give details later (right now I'm off-line and soon asleep). /Per Sent from my iPad, please ignore stupid spelling corrections! 3 dec 2012 kl. 04:48 skrev Dale Shaw dale.shaw+j-...@gmail.com: cheers, Dale (..on the never-ending quest to make SRXs behave like routers w/IPsec) ___ 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] export OSPF routes as type 1
I'm trying to export some OSPF routes as type 1 external instead of the
default type 2 external.
I can't seem to find where it is done - I thought it would be done in the
policy map but I don't see an option.
policy-options {
policy-statement my-ospf-export-policy {
term static-and-direct-as-type-1 {
from protocol [ static direct ];
then {
external {
type 1;
}
accept;
}
}
}
}
- CK.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
