it`s give me error message:
[edit]
admin@CIG-HQ# set security zones security-zone trust15 interfaces irb.1
error: interface-unit: 'irb.1': This interface cannot be configured in a zone
error: statement creation failed: irb.1
↧
Re: SRX1400 Trunk Issue
↧
Re: SRX1400 Trunk Issue
I don't have high end SRX at my disposal so this is just an educated guess..
I would try the following
ge-0/0/9 {
vlan-tagging
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list 2-17;
}
}
unit 1 {
family bridge {
interface-mode trunk;
vlan-id-list 1;
}And then assign ge-0/0/9.1 to the security policy and allow host inbout traffic.
Regards, Wojtek
↧
↧
Re: SRX1400 Trunk Issue
Instead of vla-id list, can you try configuing only one vlan (access port) on these ports on SRX and check if you are able to ping through SRX?
https://kb.juniper.net/InfoCenter/index?page=content&id=KB21421
↧
Re: SRX1400 Trunk Issue
i am tring that but still pinging not wotk
↧
Re: SRX1400 Trunk Issue
All the examples I've found are using subinterfaces on the trunk with single vlan id in the vlan-id-list
ge-0/0/9 {
vlan-tagging
unit 1 {
family bridge {
interface-mode trunk;
vlan-id-list 1;
unit 2 {
family bridge {
interface-mode trunk;
vlan-id-list 2;
unit 3 {
family bridge {
interface-mode trunk;
vlan-id-list 3;
#and so forth
}Can you try this approach?
Regards, Wojtek
↧
↧
Re: SRX1400 Trunk Issue
when i transfered all ports to access vlan 1, its working for vlan 1 only
↧
Re: SRX1400 Trunk Issue
thx for reply, i will try this tomorrow while my duty time is finished for today
↧
Re: SRX340 with Filter-Based Forwarding Issue
Right now, the AP can reach the Internet and I'm checking with local support.
Refer to the traceroute from SRX, the AP traffic is still leaving the original path.
You can refer to the attached result for reference.
↧
more specific monitoring via automation for high-end SRX(s)
Hi all,
We have 10 high-end SRX devices. We want to do more and more specific monitoring these SRX(s) as usual existing monitoring is also covering these SRX devices. But we want to more stand out stuff for these SRXs
1-) Every morning doing health check(mem,cpu, usage, load etc) for these SRX(s)
2-) Checking logs to see wheather or not there is any error.
3-) Doing some cross check across the chassis cluster. For instance when CPU or memory usage is high than usual, doing some check the fpc, pic or deamons or other relavant things.
4-) All results and outputs should be in notepad format.
5-) These should be executed via automation(pyhton scripting) every morning at 6am
6-) Any other ideas which are workable for monitoring via automation and having realiable and robust environment of SRXs
What do you think about these monitoring things that we wishes to have?
Or does any one has any similar things in their operational environment?
I really appreciate your ideas, experiences and will forward to see your replies...
Many thanks
Erdix
↧
↧
Re: SRX340 with Filter-Based Forwarding Issue
From what I see in the trace it's working as expected. Traffic is being source NATted to the reth3.0 interface IP and the leaves via 124.65.160.169. Trace shows only traffic leaving the firewall. To see returning traffic please adjust packet-filter definition
delete security flow traceoptions packet-filter 2 destination-prefix 172.16.18.5/32 set security flow traceoptions packet-filter 2 destination-prefix 124.65.160.172/32
Regards, Wojtek
↧
Re: SRX340 with Filter-Based Forwarding Issue
Great, it means it is working finally.
I'm really appreciate your assistance.
If this internet link goes down, will it swap back to orginal link or I have to add extra comments?
I have attached the log file for your reference.
↧
Re: SRX1400 Trunk Issue
I am tried it, still no pinging, i dont no why this thing happen only in vlan 1?
↧
Re: SRX1400 Trunk Issue
Can you try to configure VLAN 1 as native on the trunk interfaces?
native-vlan-id 1;
Also please see a note from configuration guide
If you are using Layer 2 switches, you will need to set BPDU options to help prevent
STP misconfigurations that can lead to network outages. First, enable
bypass-non-ip-unicast to allow BPDUs. Next, set the bpdu-vlan-flooding option to
limit flooding of BPDUs to each VLAN; otherwise BPDUs received on one port will
be sent to all other ports even if ports are in different VLANs.
Regards, Wojtek
↧
↧
Srx 5400 -> Mikrotik CCR1036 Ipsec over Gre
Hello
I am trying to get Gre / ipsec tunnel between Juniper srx 5400 and mikrotik ccr1036. Ipsec tunnel and gre tunnel seperately work. But i would like to have gre tunnel and everyting that passes over that tunnel to get ipsec encrypted. I need this because mikrotik nativly dont make interface with ipsec tunnel and therefore i cant use ospf. Sofar i have tryed few different ways to get it working, currently i have gre tunnel up and ipsec connection established over it but i cant ping pc to pc in different subnets. i think its ipsec policy issue. Same setup (gre and ipsec over gre) works just fine with two mikrotiks but i need one end to be juniper.
Juniper:
## Last changed: 2018-06-12 09:14:47 UTC
version 15.1X49-D120.3;
system {
host-name SRX1;
root-authentication {
encrypted-password ""; ## SECRET-DATA
}
services {
ssh;
web-management {
http;
}
}
}
security {
ike {
proposal ike-phase1-proposal {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;
lifetime-seconds 3600;
}
policy ike-phase1-policy {
mode main;
proposals ike-phase1-proposal;
pre-shared-key ascii-text "$9$2woZjmfzCtOHqtO1RlegoJ"; ## SECRET-DATA
}
gateway gw-chicago {
ike-policy ike-phase1-policy;
address 10.255.7.98;
no-nat-traversal;
local-identity inet 10.255.7.97;
remote-identity inet 10.255.7.98;
external-interface gr-0/0/0;
}
}
ipsec {
proposal ipsec-phase2-proposal {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;
lifetime-seconds 3600;
}
policy ipsec-phase2-policy {
perfect-forward-secrecy {
keys group2;
}
proposals ipsec-phase2-proposal;
}
vpn ike-vpn-chicago {
bind-interface st0.0;
ike {
gateway gw-chicago;
proxy-identity {
local 192.168.3.0/24;
remote 192.168.88.0/24;
service any;
}
ipsec-policy ipsec-phase2-policy;
}
establish-tunnels immediately;
}
}
policies {
from-zone Sise to-zone vpn-chicago {
policy vpn-tr-chi {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone vpn-chicago to-zone Sise {
policy vpn-chi-tr {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone Gre to-zone Sise {
policy gre-sise {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone Sise to-zone Gre {
policy sise-gre {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
default-policy {
permit-all;
}
}
zones {
security-zone Sise {
address-book {
address V6rk 192.168.3.0/24;
address V6rkGre 10.255.7.96/30;
}
interfaces {
ge-2/1/0.0 {
host-inbound-traffic {
system-services {
all;
}
protocols {
inactive: vrrp;
inactive: ospf;
all;
}
}
}
}
}
security-zone AsoV2line {
interfaces {
xe-2/2/0.0 {
host-inbound-traffic {
system-services {
ping;
ike;
}
}
}
}
}
security-zone vpn-chicago {
address-book {
address V6rk 192.168.88.0/24;
address V6rkGre 10.255.7.96/30;
}
interfaces {
st0.0;
}
}
security-zone Gre {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
gr-0/0/0.0;
}
}
}
}
interfaces {
gr-0/0/0 {
unit 0 {
tunnel {
source 195.90.100.10;
destination 195.90.100.12;
}
family inet {
address 10.255.7.97/30;
}
}
}
ge-2/1/0 {
description Sisev6rk;
unit 0 {
family inet {
address 192.168.3.253/24 {
vrrp-group 1 {
virtual-address 192.168.3.1;
priority 200;
preempt;
accept-data;
}
}
}
}
}
xe-2/2/0 {
description Aso_Uplink;
unit 0 {
family inet {
address 195.90.100.10/29;
}
}
}
fxp0 {
description Management;
unit 0 {
family inet {
address 10.200.200.1/24;
}
}
}
st0 {
unit 0 {
family inet;
}
}
}
routing-options {
static {
route 192.168.88.0/24 next-hop gr-0/0/0.0;
}
}
Mikrotik:
/interface ethernet
set [ find default-name=ether1 ] comment="V\E4lis"
set [ find default-name=ether2 ] comment=Sise
set [ find default-name=ether3 ] disabled=yes
set [ find default-name=ether4 ] disabled=yes
set [ find default-name=ether5 ] disabled=yes
set [ find default-name=ether6 ] disabled=yes
set [ find default-name=ether7 ] disabled=yes
set [ find default-name=ether8 ] disabled=yes
set [ find default-name=ether9 ] disabled=yes
set [ find default-name=ether10 ] disabled=yes
set [ find default-name=ether11 ] disabled=yes
set [ find default-name=ether12 ] disabled=yes
set [ find default-name=sfp1 ] disabled=yes
set [ find default-name=sfp2 ] disabled=yes
set [ find default-name=sfp3 ] disabled=yes
set [ find default-name=sfp4 ] disabled=yes
/interface gre
add allow-fast-path=no !keepalive local-address=195.90.100.12 name=\
gre-tunnel1 remote-address=195.90.100.10
/interface list
add name=Discovery
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip ipsec proposal
set [ find default=yes ] disabled=yes
add enc-algorithms=aes-128-cbc name=proposal1
/routing ospf area
set [ find default=yes ] disabled=yes
/routing ospf instance
set [ find default=yes ] disabled=yes router-id=172.17.1.1
/ip neighbor discovery-settings
set discover-interface-list=Discovery
/interface list member
add interface=ether2 list=Discovery
/ip address
add address=192.168.88.1/24 interface=ether2 network=192.168.88.0
add address=195.90.100.12/29 interface=ether1 network=195.90.100.8
add address=10.255.7.98/30 interface=gre-tunnel1 network=10.255.7.96
/ip cloud
set update-time=no
/ip ipsec peer
add address=195.90.100.10/32 dh-group=modp1024 disabled=yes dpd-interval=\
disable-dpd enc-algorithm=aes-128 lifetime=30m nat-traversal=no secret=\
juniper
add address=10.255.7.97/32 dh-group=modp1024 dpd-interval=disable-dpd \
enc-algorithm=aes-128 lifetime=30m nat-traversal=no secret=juniper
/ip ipsec policy
set 0 disabled=yes
add disabled=yes dst-address=192.168.3.0/24 proposal=proposal1 \
sa-dst-address=195.90.100.10 sa-src-address=195.90.100.12 src-address=\
192.168.88.0/24 tunnel=yes
add dst-address=192.168.3.0/24 proposal=proposal1 sa-dst-address=10.255.7.97 \
sa-src-address=10.255.7.98 src-address=192.168.88.0/24 tunnel=yes
/ip route
add distance=1 dst-address=192.168.3.0/24 gateway=gre-tunnel1
add disabled=yes distance=1 dst-address=192.168.3.0/24 gateway=ether1
/system routerboard settings
set silent-boot=no
Egert
↧
Re: SRX1400 Trunk Issue
it`s given me this message:
admin@CIG-HQ# set interfaces ge-0/0/9 vlan-tagging native-vlan-id 1
[edit]
admin@CIG-HQ# commit
[edit interfaces ge-0/0/9 native-vlan-id]
'native-vlan-id 1'
native-vlan-id can be specified with flexible-vlan-tagging mode or with interface-mode trunk
error: commit failed: (statements constraint check failed)
and i added this commands as you mintion:
security {
flow {
bridge {
bypass-non-ip-unicast;
bpdu-vlan-flooding;
↧
Re: SRX1400 Trunk Issue
Just replace vlan-tagging with flexible-vlan-tagging and try again.
delete interfaces ge-0/0/9 vlan-tagging set interfaces ge-0/0/9 flexible-vlan-tagging set interfaces ge-0/0/9 native-vlan-id 1
Regards, Wojtek
↧
RPM/IP Monitoring - Slow Failback
I'd like to configure my SRX to wait 15 minutes to fail back to the default route after installing a different next-hop via rpm/ip monitoring. Is there a way to do this?
↧
↧
Re: RPM/IP Monitoring - Slow Failback
You can use "within" option with "trigger". For example if your rpm executed once in 1 min , so you need to check if rpm was succesful 15 times
We configured this some time ago
services {
rpm {
probe script {
test src1 {
probe-type icmp-ping;
target address 10.7.0.1;
probe-count 1;
probe-interval 1;
test-interval 1;
source-address 10.7.0.2;
}
}
event-options {
policy ping-fail-src1 {
events ping_probe_failed;
within 32 {
trigger on 15;
}
attributes-match {
ping_probe_failed.test-owner matches .*script.*;
ping_probe_failed.test-name matches .*src1.*;
}
then {
event-script change-nexthop.slax {
arguments {
nexthop-address 10.7.0.1;
metric 20;
}
}
}
}
policy ping-success-src1 {
events ping_test_completed;
within 31 {
trigger on 15;
events ping_test_completed;
}
attributes-match {
ping_test_completed.test-owner matches .*script.*;
ping_test_completed.test-name matches .*src1.*;
}
then {
event-script change-nexthop.slax {
arguments {
nexthop-address 10.7.0.1;
metric 10;
}
}
}
}
}
↧
automatic route change as per tunnel state
Hi ,
In my below configuration 192.168.2.0/24 has going via st0.2 & st0.3 , my default preference is st0.2. whenever st0.2 goes down 2.x should go via st0.3 but my problem is when ever st0.2 is down 2.x going via st0.2 but taking more time and once st0.3 is comes back still traffic trying to go via st0.3
I need help about what to do or how to set preferences, whenever st0.2 goes down immediately 2.x traffic should go via st0.3 and once st0.2 is comes back then traffic should go from it immediately without delay
10.11.11.0/24 *[Direct/0] 1d 21:52:21
> via st0.0
10.11.11.11/32 *[Local/0] 11w6d 06:06:31
Local via st0.0
12.11.11.0/24 *[Direct/0] 1d 22:15:16
> via st0.2
12.11.11.11/32 *[Local/0] 11w6d 06:06:31
Local via st0.2
13.11.11.0/24 *[Direct/0] 1d 19:47:17
> via st0.3
13.11.11.11/32 *[Local/0] 11w6d 06:06:31
Local via st0.3
192.168.2.0/24 *[Static/5] 1w6d 07:50:25
> via st0.2
via st0.3
192.168.6.0/24 *[Static/5] 1d 22:15:16
> via st0.2
192.168.11.0/24 *[Static/5] 1d 21:52:21
> via st0.0
192.168.20.0/24 *[Static/5] 1d 19:47:17
> via st0.3
192.168.40.0/24 *[Static/5] 1d 19:47:17
> via st0.3
static {
route 192.168.200.0/24 next-hop st0.0;
route 192.168.2.0/24 next-hop [ st0.2 st0.3 ];
route 192.168.11.0/24 next-hop st0.0;
route 192.168.202.0/24 next-hop st0.0;
route 192.168.203.0/24 next-hop st0.0;
route 192.168.201.0/24 next-hop st0.0;
route 192.168.204.0/24 next-hop st0.0;
route 0.0.0.0/0 next-hop x.x.x.x;
route 192.168.6.0/24 next-hop st0.2;
route 192.168.20.0/24 next-hop st0.3;
route 192.168.40.0/24 next-hop st0.3;
}
route 192.168.200.0/24 next-hop st0.0;
route 192.168.2.0/24 next-hop [ st0.2 st0.3 ];
route 192.168.11.0/24 next-hop st0.0;
route 192.168.202.0/24 next-hop st0.0;
route 192.168.203.0/24 next-hop st0.0;
route 192.168.201.0/24 next-hop st0.0;
route 192.168.204.0/24 next-hop st0.0;
route 0.0.0.0/0 next-hop x.x.x.x;
route 192.168.6.0/24 next-hop st0.2;
route 192.168.20.0/24 next-hop st0.3;
route 192.168.40.0/24 next-hop st0.3;
}
↧
Re: automatic route change as per tunnel state
Try if this helps
route 192.168.2.0/24 {
next-hop st0.2;
qualified-next-hop st0.3 {
preference 6;
}
}Whats on the other side of the tunnel? If also SRX there is an option to configure BFD for static routes but I'm not sure if it works with unnumbered interfaces.
https://www.juniper.net/documentation/en_US/junos/topics/example/policy-static-routes-bfd.html
Regards, Wojtek
↧