Re: [j-nsp] sshd log messages !!
set firewall family inet filter Access term AllowSSH from address X.X.X.X/16 If X.X.X.X/16 includes any interface address of this router, then this filter is NOT going to stop attacks, no matter where applied. You should be much more specific in writing the match conditions. Below is an example: X.X.X.X/16 is the trusted hosts IP block, allowed to SSH _TO_ this router set firewall family inet filter Access term AllowInboundSSH from source-address X.X.X.X/16 set firewall family inet filter Access term AllowInboundSSH from protocol tcp set firewall family inet filter Access term AllowInboundSSH from destination-port ssh set firewall family inet filter Access term AllowInboundSSH then accept Y.Y.Y.Y/16 is the another trusted hosts IP block, allowed to be SSHed to _FROM_ this router set firewall family inet filter Access term AllowOutboundSSHReturn from source-address Y.Y.Y.Y/16 set firewall family inet filter Access term AllowOutboundSSHReturn from protocol tcp set firewall family inet filter Access term AllowOutboundSSHReturn from tcp-established set firewall family inet filter Access term AllowOutboundSSHReturn from source-port ssh set firewall family inet filter Access term AllowOutboundSSHReturn then accept HTH Thanks Alex On 27/02/2014 12:13, Harri Makela wrote: Model: j6350 JUNOS Software Release [10.4R4.5] Following is the current configuration that we have for ssh:- set system login user xxx authentication ssh-rsa ssh-rsa B set system services ssh set security ssh-known-hosts host 10.x.x.x rsa-key set security ssh-known-hosts host 10.x.x.x rsa-key set firewall family inet filter Access term AllowSSH from port ssh set firewall family inet filter Access term DenySSH from port ssh Following firewall filter is in place:- set interfaces ge-0/0/1 unit 0 family inet filter input Access set firewall family inet filter Access term AllowSSH from address X.X.X.X/16 set firewall family inet filter Access term AllowSSH from address X.X.X.X/16 set firewall family inet filter Access term AllowSSH from address X.X.X.X/16 set firewall family inet filter Access term AllowSSH from address X.X.X.X/16 set firewall family inet filter Access term AllowSSH from protocol tcp set firewall family inet filter Access term AllowSSH from port ssh set firewall family inet filter Access term AllowSSH then accept set firewall family inet filter Access term DenySSH from protocol tcp set firewall family inet filter Access term DenySSH from port ssh set firewall family inet filter Access term DenySSH then reject set firewall family inet filter Access term default-term then accept I am now going to add loopback address as well:- set interfaces lo0 unit 0 family inet filter input Access Important thing is that all these alerst started when we applied the filter, may be something wrong with the ocnfiguration that we have applied. Following is the vulnerability that we wanted to address:- http://kb.juniper.net/InfoCenter/index?page=contentid=JSA10612 Thanks all for your detailed response. On Thursday, 27 February 2014, 7:11, Mark Tinka mark.ti...@seacom.mu wrote: On Thursday, February 27, 2014 01:14:26 AM Rodrigo Augusto wrote: Protect your RE. Put a filter on your loopback and permit only your netwoks to access this port(22). Yep. You really shouldn't let your SSH daemon have easy access to the world. Mark. ___ 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] sshd log messages !!
The filter the OP posted
set firewall family inet filter Access term AllowSSH from address X.X.X.X/16
set firewall family inet filter Access term AllowSSH from address X.X.X.X/16
set firewall family inet filter Access term AllowSSH from address X.X.X.X/16
set firewall family inet filter Access term AllowSSH from address X.X.X.X/16
set firewall family inet filter Access term AllowSSH from protocol tcp
set firewall family inet filter Access term AllowSSH from port ssh
set firewall family inet filter Access term AllowSSH then accept
- matches the following combo:
( { X.X.X.X/16 source, any destination } OR { any source, X.X.X.X/16
destination} )
AND
( { any src.tcp.port, 22 } OR { 22, any dst.tcp.port} )
Which means that if X.X.X.X/16 includes any local IP address, then any
host on internet can send SSH packets to this router.
Hope this makes sense.
HTH
Thanks
Alex
On 27/02/2014 15:10, Andrew Tutten wrote:
Alex,
Can you elaborate on a situation where if you have part of your source
address filter on your interface why it won't stop attacks? Is it if
SSH traffic is passing through that interface to get to the router? I
have had problems with still seeing logins from addresses outside the
filter on mine.
Thanks.
On Thu, Feb 27, 2014 at 7:44 AM, Alex Arseniev
arsen...@btinternet.com mailto:arsen...@btinternet.com wrote:
set firewall family inet filter Access term AllowSSH from address
X.X.X.X/16
If X.X.X.X/16 includes any interface address of this router, then
this filter is NOT going to stop attacks, no matter where applied.
You should be much more specific in writing the match conditions.
Below is an example:
X.X.X.X/16 is the trusted hosts IP block, allowed to SSH
_TO_ this router
set firewall family inet filter Access term AllowInboundSSH from
source-address X.X.X.X/16
set firewall family inet filter Access term AllowInboundSSH from
protocol tcp
set firewall family inet filter Access term AllowInboundSSH from
destination-port ssh
set firewall family inet filter Access term AllowInboundSSH then
accept
Y.Y.Y.Y/16 is the another trusted hosts IP block, allowed
to be SSHed to _FROM_ this router
set firewall family inet filter Access term AllowOutboundSSHReturn
from source-address Y.Y.Y.Y/16
set firewall family inet filter Access term AllowOutboundSSHReturn
from protocol tcp
set firewall family inet filter Access term AllowOutboundSSHReturn
from tcp-established
set firewall family inet filter Access term AllowOutboundSSHReturn
from source-port ssh
set firewall family inet filter Access term AllowOutboundSSHReturn
then accept
HTH
Thanks
Alex
On 27/02/2014 12:13, Harri Makela wrote:
Model: j6350
JUNOS Software Release [10.4R4.5]
Following is the current configuration that we have for ssh:-
set system login user xxx authentication ssh-rsa ssh-rsa B
set system services ssh
set security ssh-known-hosts host 10.x.x.x rsa-key
set security ssh-known-hosts host 10.x.x.x rsa-key
set firewall family inet filter Access term AllowSSH from port ssh
set firewall family inet filter Access term DenySSH from port ssh
Following firewall filter is in place:-
set interfaces ge-0/0/1 unit 0 family inet filter input Access
set firewall family inet filter Access term AllowSSH from
address X.X.X.X/16
set firewall family inet filter Access term AllowSSH from
address X.X.X.X/16
set firewall family inet filter Access term AllowSSH from
address X.X.X.X/16
set firewall family inet filter Access term AllowSSH from
address X.X.X.X/16
set firewall family inet filter Access term AllowSSH from
protocol tcp
set firewall family inet filter Access term AllowSSH from port ssh
set firewall family inet filter Access term AllowSSH then accept
set firewall family inet filter Access term DenySSH from
protocol tcp
set firewall family inet filter Access term DenySSH from port ssh
set firewall family inet filter Access term DenySSH then reject
set firewall family inet filter Access term default-term then
accept
I am now going to add loopback address as well:-
set interfaces lo0 unit 0 family inet filter input Access
Important thing is that all these alerst started when we
applied the filter, may be something wrong with the
ocnfiguration that we have applied.
Following is the vulnerability that we wanted to address:-
http://kb.juniper.net/InfoCenter/index?page=contentid=JSA10612
Thanks all for your detailed response.
On Thursday, 27 February 2014, 7:11, Mark Tinka
mark.ti...@seacom.mu mailto:mark.ti...@seacom.mu wrote:
On Thursday, February 27, 2014
Re: [j-nsp] RSVP neighbor sequence changes
Duplicate IP on this shared segment? Just my guess... HTH Thanks Alex On 04/02/2014 14:38, Eric Van Tol wrote: Hi all, Two sets of routers in my network keep logging the following message: rpd[1559]: RPD_RSVP_NBRDOWN: RSVP neighbor x.x.x.x down on interface ae0.1 nbr-type Direct, neighbor seq number change The interface is different on the two sets of routers, obviously. All other RSVP sessions seem to work fine: RSVP neighbor: 6 learned Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd x.x.x.x 0 2/1 12w4d 21:39:069 1282869/1282869 376297 x.x.x.x 0 2/119:29:029 7786/7786 18297 x.x.x.x 0 1/0 3:19:299 1322/1322 11192 x.x.x.x 5 2/1 2:54:209 1238/1220 1251 x.x.x.x 0 1/019:39:339 7817/7817 41623 x.x.x.x 10 0/0 89 1361/1361 16225 It's that last one which keeps resetting every 9 seconds. Communication between the opposing interfaces is fine with no errors that I can see. I've tried disabling RSVP on both sides, but this doesn't resolve the issue when it's re-enabled. What type of situation can cause both neighbors to constantly change their sequence number? RFC3209 shows: This value MUST change when the sender is reset, when the node reboots, or when communication is lost to the neighboring node and otherwise remains the same. None of those conditions appear to be getting met, so I'm a bit puzzled. -evt ___ 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] MX ping - ToS overrided
You are monitoring ToS in ICMP ECHO REPLY, not request. And that can be set/overridden anywhere by QoS policies, i.e. - on Google DNS server 8.8.8.8 itself - on any transit network HTH Thanks Alex On 22/01/2014 14:21, Arash Alizadeh wrote: Hi, I'm experiencing issues when initating ToS ping from MX devices. The specified ToS argument just seems to be overrided to dec 192 when leaving the interface. I verified this with the traffic monitor on the egress interface: user@node ping 8.8.8.8 tos 96 64 bytes from 8.8.8.8: icmp_seq=0 ttl=246 time=15.675 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=246 time=15.385 ms user@node monitor traffic interface xe-0/0/0.0 extensive matching icmp PFE proto 2 (ipv4): (tos 0xc0, ttl 255, id 16332, offset 0, flags [none], proto: ICMP (1), length: 84) x.x.x.x 8.8.8.8: ICMP echo reply, id 47826, seq 0, length 64 14:06:58.721197 Out I've tried this on 11.4R6.6 and 12.3R4-S2 (ppc and 64-bit) boxes with the same result. Did anyone else ran into this issue? Any input is appriciated. Regards, Arash ___ 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] fxp0.0 interface match in firewall filter doesn't work in JUNOS 12.3R5.7
You should be able to do negative match on interface-group:
1/ mark all other interfaces with interface-group:
set interfaces xe-0/0/0.0 family inet filter group 100
2/ match on interface-group-except in lo0.0 FW filter
set firewall family inet filter RE-PROTECT term 1 from
interface-group-except 100
(1) can be done with configuration-groups, i.e.
set group ALL-ETHS interfaces [xg]e-* unit * family inet filter
group 100
I have this successfully working in customer's production since Q3 2009.
It does stop spoofed src.ip attacks if spoofed packets are coming from
interface other than fxp0.0.
Thanks
Alex
On 21/01/2014 01:35, Tore Anderson wrote:
This is a heads-up to anyone planning to upgrade to 12.3R5.7, especially
if you don't have easy access to the serial console, but only a firewall
term such as:
term allow-oob-management {
from {
interface fxp0.0;
}
then accept;
}
...in your lo0.0 input filter (which presumably then goes on to drop all
unmatched traffic): It simply doesn't work.
I've confirmed on both MX80 and MX240, several times. After a reboot,
the term just gets skipped, it seems. Deactivating the term, committing,
and then reactivating it fixes the problem but that might of course be
easier said than done if locked out of the box.
Terms doing source-address matches seems to work fine.
Tore
___
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] M-series IPSEC / SP interface and VRF
And what happens if You ping a destination IP known via BGP across the
tunnel but with different src.ip?
ping routing-instance VRFname dst.ip source whatever
This src.ip must be known by/reachable from far end.
HTH
Thanks
Alex
On 17/12/2013 20:40, Scott Harvanek wrote:
BGP is running in the tunnel and the next hop is the far side of the
tunnel, everything looks correct. All the routes show the far end of
the tunnel and BGP is established inside the VRF but traffic will not
pass except of traffic directly between the two endpoints. E.g.
BGP/ICMP on the tunnel subnet. I'm at a loss.
I'll pull some info and post it back, maybe someone sees something I
don't.
Scott H.
On 12/17/13, 12:27 PM, Alex Arseniev wrote:
For the traffic to be encrypted, the BGP nexthop has to point into
the tunnel which means one of the below:
1/ BGP has to run inside the tunnel, or
2/ You have to have a BGP import policy to change the nexthop to
tunnel's remote address. If this is eBGP, then also add
accept-remote-nexthop knob.
HTH
Thanks
Alex
On 17/12/2013 16:08, Scott Harvanek wrote:
So this works to establish the tunnels, the problem is, BGP received
routes over the tunnel do not function correctly. The routes are
properly installed in the VRF but traffic to those destinations does
not pass correctly. Does anyone have any experience running BGP like
this on the m-series or does it just not work on next-hop-style?
Thanks,
-SH
On 11/12/13, 1:34 PM, Scott Harvanek wrote:
Yep excellent, I'll give it a whirl, thanks!
Scott H.
On 11/12/13, 1:24 PM, Alex Arseniev wrote:
So, if I understand Your requirement, You want sp-0/0/0.unit in
VRF, correct?
And outgoing GE interface in inet.0?
And where the decrypted packets should be placed, inet.0 or VRF?
And where from the to-be-ecrypted packets should arrive, from
inet.0 or VRF?
If the answer is correct/inet.0/VRF/VRF then migrate to
next-hop-style IPSec and place inside sp-* unit into the VRF
leaving outside sp-* unit in inet.0.
HTH
Thanks
Alex
On 12/11/2013 16:35, Scott Harvanek wrote:
Alex,
Yea, tried this but it looks like you can't set it to the default
inet.0 instance, only to things different... the local gw in my
case is in the default instance and I want the service interface
in another so unless I'm mistaken it's in default by default and
this fails?
Scott H.
On 11/12/13, 11:22 AM, Alex Arseniev wrote:
Yes
[edit]
aarseniev@m120# set services service-set SS1 ipsec-vpn-options
local-gateway ?
Possible completions:
addressLocal gateway address
routing-instance Name of routing instance that hosts local
gateway = CHECK THIS OUT!!!
aarseniev@m120 show version
Hostname: m120
Model: m120
JUNOS Base OS boot [10.4S7.1]
HTH
Thanks
Alex
On 12/11/2013 16:05, Scott Harvanek wrote:
Anyone with any ideas on this?
Scott H.
On 11/9/13, 12:58 PM, Scott Harvanek wrote:
Is there a way to build a IPSec tunnel / service interface
where the local gateway is NOT in the same routing-instance as
the service interface?
Here's what I'm trying to do;
[ router A (SRX) ] == Switch / IS-IS mesh == [ router B m10i ]
[ st0.0 / VRF ] = [ sp-0/0/0.0 / VRF ]
The problem is, I want sp-0/0/0.0 on router B in a VRF but NOT
the outside interface on router B, I cannot commit unless the
outside/local-gateway on the IPSec tunnel is in the same
routing-instance as the service interface, is there a way
around this? The SRX devices can do this without issue.
service-set {
interface-service {
service-interface sp-0/0/0.0; -- want this in a VRF
}
ipsec-vpn-options {
local-gateway x.x.x.x; -- default routing instance
}
ipsec-vpn-rules
}
___
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
___
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
___
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] M-series IPSEC / SP interface and VRF
For the traffic to be encrypted, the BGP nexthop has to point into the
tunnel which means one of the below:
1/ BGP has to run inside the tunnel, or
2/ You have to have a BGP import policy to change the nexthop to
tunnel's remote address. If this is eBGP, then also add
accept-remote-nexthop knob.
HTH
Thanks
Alex
On 17/12/2013 16:08, Scott Harvanek wrote:
So this works to establish the tunnels, the problem is, BGP received
routes over the tunnel do not function correctly. The routes are
properly installed in the VRF but traffic to those destinations does
not pass correctly. Does anyone have any experience running BGP like
this on the m-series or does it just not work on next-hop-style?
Thanks,
-SH
On 11/12/13, 1:34 PM, Scott Harvanek wrote:
Yep excellent, I'll give it a whirl, thanks!
Scott H.
On 11/12/13, 1:24 PM, Alex Arseniev wrote:
So, if I understand Your requirement, You want sp-0/0/0.unit in
VRF, correct?
And outgoing GE interface in inet.0?
And where the decrypted packets should be placed, inet.0 or VRF?
And where from the to-be-ecrypted packets should arrive, from inet.0
or VRF?
If the answer is correct/inet.0/VRF/VRF then migrate to
next-hop-style IPSec and place inside sp-* unit into the VRF leaving
outside sp-* unit in inet.0.
HTH
Thanks
Alex
On 12/11/2013 16:35, Scott Harvanek wrote:
Alex,
Yea, tried this but it looks like you can't set it to the default
inet.0 instance, only to things different... the local gw in my
case is in the default instance and I want the service interface in
another so unless I'm mistaken it's in default by default and this
fails?
Scott H.
On 11/12/13, 11:22 AM, Alex Arseniev wrote:
Yes
[edit]
aarseniev@m120# set services service-set SS1 ipsec-vpn-options
local-gateway ?
Possible completions:
addressLocal gateway address
routing-instance Name of routing instance that hosts local
gateway = CHECK THIS OUT!!!
aarseniev@m120 show version
Hostname: m120
Model: m120
JUNOS Base OS boot [10.4S7.1]
HTH
Thanks
Alex
On 12/11/2013 16:05, Scott Harvanek wrote:
Anyone with any ideas on this?
Scott H.
On 11/9/13, 12:58 PM, Scott Harvanek wrote:
Is there a way to build a IPSec tunnel / service interface where
the local gateway is NOT in the same routing-instance as the
service interface?
Here's what I'm trying to do;
[ router A (SRX) ] == Switch / IS-IS mesh == [ router B m10i ]
[ st0.0 / VRF ] = [ sp-0/0/0.0 / VRF ]
The problem is, I want sp-0/0/0.0 on router B in a VRF but NOT
the outside interface on router B, I cannot commit unless the
outside/local-gateway on the IPSec tunnel is in the same
routing-instance as the service interface, is there a way around
this? The SRX devices can do this without issue.
service-set {
interface-service {
service-interface sp-0/0/0.0; -- want this in a VRF
}
ipsec-vpn-options {
local-gateway x.x.x.x; -- default routing instance
}
ipsec-vpn-rules
}
___
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
___
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
___
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] M-series IPSEC / SP interface and VRF
Yes
[edit]
aarseniev@m120# set services service-set SS1 ipsec-vpn-options
local-gateway ?
Possible completions:
addressLocal gateway address
routing-instance Name of routing instance that hosts local
gateway = CHECK THIS OUT!!!
aarseniev@m120 show version
Hostname: m120
Model: m120
JUNOS Base OS boot [10.4S7.1]
HTH
Thanks
Alex
On 12/11/2013 16:05, Scott Harvanek wrote:
Anyone with any ideas on this?
Scott H.
On 11/9/13, 12:58 PM, Scott Harvanek wrote:
Is there a way to build a IPSec tunnel / service interface where the
local gateway is NOT in the same routing-instance as the service
interface?
Here's what I'm trying to do;
[ router A (SRX) ] == Switch / IS-IS mesh == [ router B m10i ]
[ st0.0 / VRF ] = [ sp-0/0/0.0 / VRF ]
The problem is, I want sp-0/0/0.0 on router B in a VRF but NOT the
outside interface on router B, I cannot commit unless the
outside/local-gateway on the IPSec tunnel is in the same
routing-instance as the service interface, is there a way around
this? The SRX devices can do this without issue.
service-set {
interface-service {
service-interface sp-0/0/0.0; -- want this in a VRF
}
ipsec-vpn-options {
local-gateway x.x.x.x; -- default routing instance
}
ipsec-vpn-rules
}
___
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] M-series IPSEC / SP interface and VRF
So, if I understand Your requirement, You want sp-0/0/0.unit in VRF,
correct?
And outgoing GE interface in inet.0?
And where the decrypted packets should be placed, inet.0 or VRF?
And where from the to-be-ecrypted packets should arrive, from inet.0 or VRF?
If the answer is correct/inet.0/VRF/VRF then migrate to next-hop-style
IPSec and place inside sp-* unit into the VRF leaving outside sp-* unit
in inet.0.
HTH
Thanks
Alex
On 12/11/2013 16:35, Scott Harvanek wrote:
Alex,
Yea, tried this but it looks like you can't set it to the default
inet.0 instance, only to things different... the local gw in my case
is in the default instance and I want the service interface in another
so unless I'm mistaken it's in default by default and this fails?
Scott H.
On 11/12/13, 11:22 AM, Alex Arseniev wrote:
Yes
[edit]
aarseniev@m120# set services service-set SS1 ipsec-vpn-options
local-gateway ?
Possible completions:
addressLocal gateway address
routing-instance Name of routing instance that hosts local
gateway = CHECK THIS OUT!!!
aarseniev@m120 show version
Hostname: m120
Model: m120
JUNOS Base OS boot [10.4S7.1]
HTH
Thanks
Alex
On 12/11/2013 16:05, Scott Harvanek wrote:
Anyone with any ideas on this?
Scott H.
On 11/9/13, 12:58 PM, Scott Harvanek wrote:
Is there a way to build a IPSec tunnel / service interface where
the local gateway is NOT in the same routing-instance as the
service interface?
Here's what I'm trying to do;
[ router A (SRX) ] == Switch / IS-IS mesh == [ router B m10i ]
[ st0.0 / VRF ] = [ sp-0/0/0.0 / VRF ]
The problem is, I want sp-0/0/0.0 on router B in a VRF but NOT the
outside interface on router B, I cannot commit unless the
outside/local-gateway on the IPSec tunnel is in the same
routing-instance as the service interface, is there a way around
this? The SRX devices can do this without issue.
service-set {
interface-service {
service-interface sp-0/0/0.0; -- want this in a VRF
}
ipsec-vpn-options {
local-gateway x.x.x.x; -- default routing instance
}
ipsec-vpn-rules
}
___
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
___
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] J-series, hoping packets between routing-instances
Hello, Multiple routing-instances with next-table statics is a supported SRX configuration, see http://www.juniper.net/techpubs/en_US/junos12.1/topics/example/nat-security-mutiple-isp-configuring.html You can shortcut packets between RI with lt-* interfaces as well, but lt-* interfaces are not supported in SRX cluster. HTH Thanks Alex On 07/11/2013 14:37, Mike Williams wrote: Hi all, I might have painted myself into a corner here, so I'm here looking for options from people far cleverer than I. Firstly, a bit of history. We're using J6350s, and SRX650s, as security devices on a stick. Our Ms and MXs punt packets into a routing instance on the security devices with firewall filters. Those routing instances purposely only use the most basic of static routes possible (10/8, 192.168/16, etc), so we can be certain what zones packets pass through so the policies match. That all works fine. We're also centralising our inter-site IPSec onto the Js and SRXs, but need OSPF there, so have a second routing-instance and a partial mesh of routed tunnels between them. Still, all good. Offices and what-not have tunnels tied directly to the IPSec routing-instances and OSPF metrics keep traffic flows sane. All hunky dory. Now the problem. I need to take traffic from servers behind an M/MX have it policy'd by the security routing instance, then encrypted by the IPSec routing-instance. If I punt traffic into security, let it come back to the router, then punt it back into ipsec, everything works as expected. However each packet has to pass across the M/MX-J/SRX link 4 times, in out, in out. Shake it all about. Obviously this would be better if we could shortcut the M/MX step in the middle and move packets from security to ipsec, and ipsec to security directly. As security doesn't run OSPF/BGP/ISIS/etc adding a static route next-table ipsec.inet.0 is fine. ipsec *does* run OSPF though, so I need to do FBF to override that. I've tried a then routing-instance security filter applied on output on the interface facing the M/MX, but my traffic get lost somewhere. Security policies from 'input-ipsec-zone' to 'output-security-zone' were added. I'm wondering if 'moving' packets from routing-instance to routing-instance on a flow-mode device simply screws up security policies. As one of the input or output interface don't exist in the routing-instance. So I figured *routing* packets from routing-instance to routing-instance would be better. Time for some logical tunnels! J-series devices don't support logical tunnels though. Argh! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] l2circuit to bridge domain
routing instance-type virtual-switch (VS) + bridge-domain (BD) inside that VS. One limitation is that You cannot do VLAN manipulation in the middle between l2circuit and BD whereas You can on a physical cable loop. HTH Thanks Alex On 14/10/2013 19:31, Michail Litvak wrote: Hello, I have l2-pseudowire with tagged ethernet port on other side (encapsulation ethernet) And I receive this l2circuit on Juniper MX and want to unpack trunk to separate vlan's (connect to a few bridge domains). Are there any ideas except hairpin between two ports with l2circuit on one and subinterfaces on another ? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] l2circuit (martini) vlan-mismatch
- Original Message - From: Saku Ytti s...@ytti.fi To: juniper-nsp@puck.nether.net Everything works just fine. Only I find it really strange B-END cannot push arbitrary S-VLAN, considering A-END is going to change it anyhow. If it's not 101, A-END vill be down with 'vlan-mismatch'. Use explicit encapsulation-type ethernet under [protocols l2circuit interface ] and You won't be seeing this mismatch. On both sides of course. HTH Thanks Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] R: RE : multicast issue
- Original Message - From: david@orange.com To: dim0sal dim0...@hotmail.com Cc: juniper-nsp@puck.nether.net Sent: Tuesday, July 16, 2013 8:49 PM Subject: Re: [j-nsp] R: RE : multicast issue If you can't start/stop manually mcast streams you will never have stable counters and can't detect packet loss. This is not exactly true. What You can do with constantly running streams is to have a FW filter with specific term matching on chosen stream IP headers+count action, on both headend (HE) and tailend (TE). Then activate/deactivate this term as required. You have to have both HE and TE synced via common NTP source and perform commits at precise times (commit at if You do it manually). Assuming headend and tailed are same router models and You have no network loss, You MAY get some minuscule counter difference between HE/TE because time spent by Routing Engine doing commit slightly varies. What would be more important is to monitor whether this difference changes with time which indicates packet loss. HTH Thanks Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Logging usage on an SRX with UTM
Haven't You checked the manual? http://www.juniper.net/techpubs/en_US/junos12.1/information-products/topic-collections/syslog-messages/jd0e61552.html#WEBFILTER_URL_PERMITTED http://www.juniper.net/techpubs/en_US/junos12.1/information-products/topic-collections/syslog-messages/jd0e61552.html#WEBFILTER_URL_BLOCKED Regarding and who - the WEBFILTER syslog messages contain only the src.IP, correlation to username is manual at this stage. HTH Thanks Alex - Original Message - From: Skeeve Stevens skeeve+juniper...@eintellegonetworks.com To: juniper-nsp@puck.nether.net Sent: Sunday, June 23, 2013 12:24 PM Subject: [j-nsp] Logging usage on an SRX with UTM Hey all, Got a customer who is using a small SRX with UTM (Web filtering, AV, AS, IDP), and he wants us to do logging across with the board, but with specific focus on the usage of web traffic. They'd like to know all web urls going through the firewalls, but also very interested in the knock backs from EWF - and who. Is there something that easily does this, or something I'd have to collate via syslog, or some other method? ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/networkceoau ; blog: www.network-ceo.net The Experts Who The Experts Call Juniper - Cisco - Cloud ___ 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] SLAX script, redefining variables
The checks can be embedded into if/for-each constructs, see example here
https://code.google.com/p/junoscriptorium/source/browse/trunk/library/public/op/display/op-show-lsp-interface/op-show-lsp-interface.slax
if ($ifdescrdb/logical-interface[name == $if]/description) {
The above means that only IFLs whose name XML tag matches a string stored
in variable $if will be processed.
HTH
Thanks
Alex
- Original Message -
From: Tom Storey t...@snnap.net
To: juniper-nsp@puck.nether.net
Sent: Friday, June 07, 2013 9:54 AM
Subject: [j-nsp] SLAX script, redefining variables
Hi all.
It seems that older SLAX implementations dont have the ability to redefine
variable (Juniper is calling them immutable variables). This is apparently
fixed in 1.1 on JunOS12+ boxes with something called a mutable variable
(defined with mvar instead of var) but all of the boxes I am using are not
on JunOS12+ yet.
Has anyone found a way to collect a whole bunch of information, and then
display it at the end of the script, rather than duplicating their output
code 50 times to handle the various exceptions?
e.g. a script I am writing grabs the tx/rx figures for optics and lists
them, along with the description of the interface, so I can run my op
script and get a list of power levels, grep for destination devices etc
and
see whats happening with my circuits.
But there are a couple of exceptions that I hit along the way:
1) Descriptions arent always on the physical interface, so if theres no
description there I need to look at a logical interface, which is usually
unit 0 in my case
2) SONET interfaces dont use the same variable to store the rx power
figure as ethernet interfaces, so depending on the interface type I need
to
look at a different variable for the rx power figure
To handle these exceptions would be quite easy if I could simply use a
bunch of IF blocks to test for the various locations of the information I
want, set them in to variables, and then at the end dump it out to the
screen.
But without being able to redefine a variable, and with variables defined
inside an IF block not being accessible outside of that IF block, I will
need to reproduce my output code numerous times.
Anyone know of a solution?
Thanks
Tom
___
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 instances - ospf - summarization
To export a summarized route, having at least 1 more-specific contributing route is necessary and sufficient. I.e. if You have 10.10.10.1/32 as Type-1 in OSPF area X, then creating a Type-3 summary (to announce from area X to any other area including 0) is easy: set routing-instances RIX protocols ospf area X range 10.10.0.0/16 Of course, if You have disparate address blocks in RI1 and RI2, then You cannot export Type-3 all-RI2-prefixes-summary from RI1 if a more specific does not exist in RI1. And external/Type5|7 OSPF routes can be only summarized on ASBR (the place where Type-5|7 are created in 1st place). HTH Thanks Alex - Original Message - From: n f pkc_...@yahoo.fr To: juniper-nsp@puck.nether.net Sent: Wednesday, June 05, 2013 6:57 AM Subject: [j-nsp] routing instances - ospf - summarization Hi all, I'm running junos 11.4 on a cluster of srx devices. I'm using two virtual instances, one for my internal networks and internet, and another one for a private network. OSPF is configured on routing instance1 (RI1) and routing instance 2 (RI2). I can export between routing instances, but I'd like to know if it was possible to export via ospf from RI2 to other physical routers a single route that summarizes all the local routes I have. (like 10.10.0.0/16, as all the routes I receive via ospf on RI2 from RI1 are included within this subnet). Does anyone know if it is possible to do so ? (maybe OSPF doesn't allow that at all). thanks ___ 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] SRX 3600 dropped packets - how to debug?
- Original Message - From: Phil Mayers p.may...@imperial.ac.uk To: Wood, Peter (ISS) p.w...@lancaster.ac.uk Cc: juniper-nsp@puck.nether.net Sent: Friday, May 24, 2013 12:02 PM Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug? At the moment, the SRX is sitting in front of our personally owned VRF; this means all our wireless and wired laptops, and RAS VPN address ranges. If You run any kind peer-to-peer apps (uTorrent, eMule, etc, also includes Skype) then You'll see that outside peers trying to establish LOADS of unsolicited connection to Your inside hosts. And all of them will be dropped unless You enable full cone NAT. HTH Thanks Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unable to ping all NE when MAC are learned in Bridge group
gARP is not reliable and Your NE devices' ARP cache still contains old MAC
from old default GW.
You have to revisit them one by one and clear their arp caches, or change
IRB MAC to that of old default GW' MAC.
HTH
Thanks
Alex
- Original Message -
From: Jason Fortier jasoncfort...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Tuesday, April 30, 2013 6:18 PM
Subject: [j-nsp] Unable to ping all NE when MAC are learned in Bridge group
Hey Guys,
We are migrating some NE to new MX-5 LER. I have started with moving mgmt
to an IRB, IRB is in the bridge domain and in the routing instance. When
cut over about half the NE are no longer accessible.
When the NE are cut back to old default GW (resides on a c7609 within a
RI)
and pass through the MX as L2 with in the bridge domain only it all works
fine. Only when cutover to the NE PE does it break on some devices.
All routing appears to be working as some NE with in the subnet
are accessible. not sure why other are not? any idea would be
appreciated.
jfortier@routermx5# show
description management irb;
mtu 1600;
unit 101 {
description Management VLAN101;
family inet {
address 10.64.0.1/24;
}
}
jfortier@routermx5# show bridge-domains
101 {
description Management VLAN 101;
domain-type bridge;
vlan-id 101;
interface ge-1/0/1.101;
interface ge-1/0/2.101;
interface ae1.101;
interface ae0.101;
interface ge-1/0/0.101;
routing-interface irb.101;
}
jfortier@routermx5# show routing-instances mgmt_nes
instance-type vrf;
interface irb.101;
interface irb.102;
route-distinguisher 10.92.6.20:3141;
vrf-target target:64512:101;
vrf-table-label;
Jason
___
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] next-hop driving me crazy
Works fine for me in the lab on MX80+JUNOS 12.3 ( I use BGP-LU though, too
busy to change to regular inet unicast:-)
[edit logical-systems MX2-RR]
aarseniev@mx80# run show route logical-system MX2-RR protocol bgp extensive
inet.0: 29 destinations, 30 routes (27 active, 0 holddown, 2 hidden)
198.18.0.6/32 (1 entry, 1 announced)
TSI:
KRT in-kernel 198.18.0.6/32 - {indirect(1048668)}
*BGPPreference: 170/-101
Next hop type: Indirect
Address: 0x26e8010
Next-hop reference count: 6
Source: 198.18.0.11
Next hop type: Discard
Protocol next hop: 192.0.2.1
Push 299904
Indirect next hop: 29941d8 1048668 INH Session ID: 0x280008
State: Active Int Ext
Local AS: 50928 Peer AS: 50928
Age: 5:14 Metric2: 0
Validation State: unverified
Task: BGP_50928.198.18.0.11+179
Announcement bits (2): 3-KRT 5-Resolve tree 2
AS path: 31133 50928 I (Looped: 50928)
Communities: 5:5
Accepted
Route Label: 299904
Localpref: 100
Router ID: 198.18.0.11
Secondary Tables: inet.3
Indirect next hops: 1
Protocol next hop: 192.0.2.1 Metric: 0
Push 299904
Indirect next hop: 29941d8 1048668 INH Session ID:
0x280008
[edit logical-systems MX2-RR]
aarseniev@mx80# show policy-options policy-statement set-nh
term 1 {
from {
protocol bgp;
community 5:5;
}
then {
next-hop 192.0.2.1;
accept;
}
}
[edit logical-systems MX2-RR]
aarseniev@sadok# show routing-options
static {
route 192.0.2.1/32 discard;
}
- Original Message -
From: Eric Krichbaum e...@telic.us
To: juniper-nsp@puck.nether.net
Sent: Friday, April 26, 2013 2:36 PM
Subject: [j-nsp] next-hop driving me crazy
This should be simple but I can't get the behavior I want.
Blackhole scenario. Customer set community, I want to see that community
and set next-hop to an address I have with a discard. I've tried both a
discard interface and a basic static route. Those seem ok either way.
set routing-options static route 192.0.2.1/32 discard
Route comes in and is accepted by policy. With no next-hop 192.0.2.1
action, I see it as a valid route so I know the policy is happening. When
I
add the next-hop action, the route becomes Next hop type: Unusable with
Inactive reason: Unusable path. I don't see anything special about this
and what I translated from my cisco versions doesn't look all that
different
from various black hole presentations I find.
Anyone have a magic answer?
Thanks,
Eric
___
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] SNMP on logical-system fxp0
From: Saku Ytti s...@ytti.fi And no, you would not use this FXP0 for SNMP or Netflow or whatnot. -- ++ytti And why is that may I ask? Care to elaborate? Just curious - maybe You don't know how to cook it properly :-) I personally set up SNMPv1/v2/v3 over fxp0 enough times, including SNMPv3 with separate auth/enc keys for RE0 and RE1. Many thanks Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
From: Saku Ytti s...@ytti.fi There is nothing stopping vendors from implementing netflow and SNMP in HW, allowing instant refresh of octet counters. SNMPv3 would require encryption capabilities in HW making Your idea (a) potentially too expensive and (b) prone to export restrictions==must develop maintain 2 separate HW sets, same as for JUNOS software. Netflow often is already implemented in HW. Netflow does NOT require encryption as standard (SNMPv3 does). And as Jeff mentioned, you cannot do CoPP to protect your RE from being congested by fxp0 traffic. Something simple and easy mistake to do as L2 loop in FXP0 could be disaster, and no way to protect. (a) lo0.0 filter copy is applied to fxp0 as well (b) only if You build OOB network as flat L2 I would expect L2 BUM storms affecting fxp0. The providers I worked with build their OOB networks using same design principles as their production networks - never flat L2, routed hops, every site has at least 1 (often 2 or multi-staged) firewall(s) protecting the rest of the OOB domain from rogue elements. HTH Thanks Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
From: Saku Ytti s...@ytti.fi To: juniper-nsp@puck.nether.net Sent: Thursday, April 25, 2013 4:34 PM HW port can easily go through RE if needed. Unless there is single ASIC in the box, that would be statistical multiplexing. Unless You wish to maintain full potential perf.gain from generating SNMP in HW even in case through RE, that would require RE scalability performance == sum of SNMP performances of all ASICs in the box. Clearly won't happen. (a) lo0.0 filter copy is applied to fxp0 as well It's not in HW. I feel the need to return the favour here :-) SNMPv3 generated in ASIC and transiting via RE (for the purpose of being encrypted) is NOT in HW. It would be classified as HW-assisted. Thanks Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
- Original Message - From: Saku Ytti s...@ytti.fi To: juniper-nsp@puck.nether.net Yes it's not fate-sharing forwarding-plane, but it's fate-sharing the whole control-plane. No, it is not. fxp0 is fully functional on backup RE (including Telnet/SSH/SNMP) - and backup RE by default does not run any control plane functions apart from monitoring master RE. I think this is really my point, you need * fxp0 for ssh, snmp * inband for netflow, snmp (if HW) (redundant) * rs232 to attempt recovering box from control-plane software failure Inband for high-perf Netflow - yes. Inband for SNMP - unless You want subsecond counter updates (for realtime billing maybe?) then no. And I already answered Your points regarding SNMP in HW my other email. Thanks Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
- Original Message - From: Pavel Lunin plu...@senetsy.ru To: juniper-nsp@puck.nether.net Sent: Thursday, April 25, 2013 5:48 PM Subject: Re: [j-nsp] SNMP on logical-system fxp0 25.04.2013 19:04, Alex Arseniev wrote: Netflow does NOT require encryption as standard (SNMPv3 does). Netflow or stateful log export is very often not supported on fxp0 and analogues. Even if it is, high rate of those logs can easily overwhelm RE or the link between RE and data plane. (a) lo0.0 filter copy is applied to fxp0 as well It's not in hardware. Correct. Do you expect someone to attack fxp0 from within Your OOB network? Rogue NMS server perhaps? In that case You have OOB network design problems, see my point below wrt OOB design principles. The providers I worked with build their OOB networks using same design principles as their production networks - never flat L2, routed hops, every site has at least 1 (often 2 or multi-staged) firewall(s) protecting the rest of the OOB domain from rogue elements. Even so. Why fxp0? Why not normal interface (given you have it)? Because fxp0 is free in a sense that it is included in RE price? Well, at the end it's not that important (though evident) why OOB mgt interfaces have their limitations, they just do. It is clearly evident that for every vendor product which has management built-in interfaces on control modules, these built-in interfaces on control modules cannot deliver same features perf as revenue interfaces. Do You have expectations and/or experience/examples to the contrary? Thanks Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP on logical-system fxp0
- Original Message - From: Pavel Lunin To: Alex Arseniev Cc: juniper-nsp Sent: Thursday, April 25, 2013 9:56 PM Subject: Re: [j-nsp] SNMP on logical-system fxp0 In a big enough network — anything. Broken NMS (it turns out to happen more often than I could think), malware on management PC, misconfigured something (IP address of a syslog server), intentional hack, etc. Also, routing does not mean that you don't have broadcast domains and BUM storms are not possible. [AA] if You actually still dealing with such issues in Your customer networks, my condolences. Especially sad is the issue with management PC - do Your customers use commodity Windows PC with freeware Solarwinds version as NMS? Even if you have a firewall behind each fxp0 (and how do you manage that hell of firewalls, another OOB MGT network for OOB management devices? And we still consider price of a single port? :) — I bet you don't rate limit SNMP and even ICMP on the firewalls. [AA] The firewalls are usually clustered, so if one fails, the second one takes over. [AA] The providers I worked with usually know how many ports they need now and in the nearest future so the overall cost of adding single revenue port for OOB could reach thousands of $$$ if in order to add just 1 more port the whole new FPC/DPC/MPC need to be purchased. Let's be honest, any big ISP have more than one mgt network and they rarely resemble the Eden. Just because ISPs merge and split, different BU manage different parts of the network, sometimes BU merge too, clever folks leave the company and stupid ones sometimes come, etc. This is why I'd prefer to have more tools to be sure. [AA] Not sure if I follow, if BUs are administratively separate, how having a true OOB interface (i.e. CMP in Routing Engine) would make Your life easier? It becomes even worse, when it comes to multi-vendorness. Different equipment have different limitations for those ports. And all this makes the MGT network less and less flexible. I've once been involved in a project of a centralized monitoring system deployment for a big ISP. They had about 7 different routed OOB mgt networks (Core, Access, ATM, SDH, etc), I can't even say it was wrongly done. But just the need to provide connectivity to everything ended up with GRE over NAT over GRE over NAT salted with NAT and served through GRE sort of solutions (not everywhere, but partly). I won't say all or even most, but A LOT of troubles they had, came from the limitations of dedicated mgt interfaces. [AA] I also had to do a new OOB network design for another national ISP to replace similar mess of OOB networks because this national ISP clearly saw the value of unified OOB solution. Maybe Your ISP is not educated propely on the value of well-designed OOB network? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Speed
Use TCP Optimizer to increase WSCALE/RWIN on Windows hosts to achieve better TCP perf http://www.speedguide.net/downloads.php Thanks Alex - Original Message - From: Saku Ytti s...@ytti.fi To: juniper-nsp@puck.nether.net Sent: Monday, April 08, 2013 8:13 AM Subject: Re: [j-nsp] Speed On (2013-04-08 03:46 +0200), Johan Borch wrote: of a single session with a RTT of only 8ms? The performance is the same if I use 2 switches and the clients directly connected as if i use routers between. Any idea what it could be? bw * delay = window so window / delay = bw 64k*8 / 0.008 = 64000kbps = 64Mbps To achieve 40Mbps, you'd need 40M*1000/8 * 0.008 = 48kB window make sure with tshark what your actual window size is, don't trust iperf. Best thing is to configure OS TCP stack to window scaling and dont touch iperf window settings, I don't know why, but they just seem to break stuff. Also never measure network with TCP, measure network with UDP, measure TCP stack of hosts with TCP. -- ++ytti ___ 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] srx event-options
This part won't work:
execute-commands {
commands {
set interface ge-0/0/3 disable;
commit;
Same holds true for delete interface disable.
You will need a commit script.
HTH
Thanks
Alex
- Original Message -
From: Luca Salvatore l...@ninefold.com
To: juniper-nsp@puck.nether.net
Sent: Monday, March 18, 2013 4:56 AM
Subject: [j-nsp] srx event-options
I'm playing around with some event-options on a SRX. I'm trying to make
the SRX shutdown an interface when a specific OSPF neighbour is detected
as down, then bring the interface back up once OSPF has re-established.
I have this:
[edit event-options]
lsalvatore@FWL001# show
policy shutdown_internet_if_core_down {
events rpd_ospf_nbrdown;
attributes-match {
rpd_ospf_nbrdown.neighbor-address matches 10.255.255.86;
}
then {
execute-commands {
commands {
set interface ge-0/0/3 disable;
commit;
}
}
}
}
policy bring_up_internet_when_core_is_back {
events rpd_ospf_nbrup;
attributes-match {
rpd_ospf_nbrup.neighbor-address matches 10.255.255.86;
}
then {
execute-commands {
commands {
delete interface ge-0/0/3 disable;
commit;
}
}
Should this work? I haven't been able to test it yet but it seems like it
may do what I need.
Luca
___
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] srx event-options
The OP has already tried it with the event-script but did not tell us :-)
http://forums.juniper.net/t5/Junos-Automation-Scripting/disable-interface-slax-script-not-running-not-configured/td-p/183237
I provided him with final hints and he should be able to use the script as
published - or maybe after changing the interface name in the script itself.
Thanks
Alex
- Original Message -
From: Brian Johnson bjohn...@drtel.com
To: Diogo Montagner diogo.montag...@gmail.com; Luca Salvatore
l...@ninefold.com
Cc: juniper-nsp@puck.nether.net
Sent: Monday, March 18, 2013 1:28 PM
Subject: Re: [j-nsp] srx event-options
Diogo,
I believe he is shutting down his external interface when a neighbor on
the internal interface is down.
Alex: This script looks interesting and I'd like to see the final solution
when you get it.
Thanks.
- Brian
-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
boun...@puck.nether.net] On Behalf Of Diogo Montagner
Sent: Monday, March 18, 2013 7:25 AM
To: Luca Salvatore
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] srx event-options
I think you need to review your logic. How do you expect the OSPF
adjacency
to come up if you have shutdown the interface ?
On Monday, 18 March 2013, Luca Salvatore wrote:
I'm playing around with some event-options on a SRX. I'm trying to
make
the SRX shutdown an interface when a specific OSPF neighbour is
detected
as
down, then bring the interface back up once OSPF has re-established.
I have this:
[edit event-options]
lsalvatore@FWL001# show
policy shutdown_internet_if_core_down {
events rpd_ospf_nbrdown;
attributes-match {
rpd_ospf_nbrdown.neighbor-address matches 10.255.255.86;
}
then {
execute-commands {
commands {
set interface ge-0/0/3 disable;
commit;
}
}
}
}
policy bring_up_internet_when_core_is_back {
events rpd_ospf_nbrup;
attributes-match {
rpd_ospf_nbrup.neighbor-address matches 10.255.255.86;
}
then {
execute-commands {
commands {
delete interface ge-0/0/3 disable;
commit;
}
}
Should this work? I haven't been able to test it yet but it seems like
it
may do what I need.
Luca
___
juniper-nsp mailing list juniper-nsp@puck.nether.net javascript:;
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
./diogo -montagner
JNCIE-SP 0x41A
___
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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VLAN bundles in CCC
2 things:
1/ add family ccc under ge-1/2/0.2
2/ add encapsulation ethernet under l2circuit neighbor config.
Default encaps when You use tagged units is ethernet-vlan and with
ethernet-vlan the L2circuit actually checks if VLAN ids are same on both
ends. With encapsulation ethernet this check is not done.
HTH
Thanks
Alex
- Original Message -
From: Eric Van Tol e...@atlantech.net
To: juniper-nsp@puck.nether.net
Sent: Wednesday, March 13, 2013 11:27 AM
Subject: [j-nsp] VLAN bundles in CCC
Greetings everyone,
I'm trying to configure a list of VLANs on an interface and include them
in a CCC to cross-connect them between back-to-back routers and it's not
working. I've tried several variations of what I believe is supposed to
work, but no success. Here's my topology:
Switch-A == Router-A == Router-B == Switch-B
VLAN1 from both switches to their upstream router is configured as an SVI
for basic switch connectivity. VLANs 10, 20, 30, 40, 50, and 60 are
supposed to be bundled and transported across a single interface that
connects Router-A and Router-B. I'm able to do this one VLAN at a time
(ie. one VLAN per logical unit) just fine, but I can't get a bundle to
work. I've followed the guidelines here:
http://tinyurl.com/abw64ua
but it's not working for me. Maybe I'm misunderstanding how the VLAN
bundle is supposed to be handed off to me? I see that my l2circuit is up,
but no traffic passes between nodes configured on VLAN 10. I've tried
both the 'l2circuit' and 'connections' type of CCC. I'm on an MX80
running 11.4.
Config of Router-A follows (the other is exactly the same, except the IP
addresses).
interfaces {
ge-1/2/0 {
description Switch-A;
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 1 {
vlan-id 1;
family inet {
address 192.168.1.1/30;
}
}
unit 2 {
encapsulation vlan-ccc;
vlan-id-list [ 10 20 30 40 50 60 ];
}
}
}
ge-1/2/1 {
description Router-B;
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 1 {
vlan-id 1;
family inet {
address 10.10.0.1/30;
}
family iso;
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.1/32;
}
family iso {
address 47.0001.0100.1000.0001.00;
}
}
}
protocols {
mpls {
interface ge-1/2/0.2;
interface ge-1/2/1.1;
}
isis {
interface ge-1/2/1.1;
interface lo0.0 {
passive;
}
}
ldp {
interface ge-1/2/1.1;
interface lo0.0;
}
l2circuit {
neighbor 10.0.0.2 {
interface ge-1/2/0.2 {
virtual-circuit-id 2;
no-control-word;
}
}
}
}
Thanks,
evt
___
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] thoughs on MVRP?
If you don't need to run STP on these VLANs, why not use QinQ/dot1q-tunneling? http://kb.juniper.net/InfoCenter/index?page=contentid=KB21686actp=RSS Saves you Thanks Alex - Original Message - From: Luca Salvatore l...@ninefold.com To: juniper-nsp@puck.nether.net Sent: Sunday, March 03, 2013 12:13 AM Subject: [j-nsp] thoughs on MVRP? Hi, We have a requirment to trunk about 3500 VLANs into multiple ports on some EX4200 switches in VC mode. This breaches the vmember limit but a huge amout, and once we did this I have seen lots of errors in the logs such as: fpc0 RT-HAL,rt_entry_create,2414: failed to allocate memory for route entry /kernel: RT_PFE: RT msg op 3 (PREFIX CHANGE) failed, err 5 (Invalid) fpc0 RT-HAL,rt_entry_add_msg_proc,2702: route entry create failed fpc0 RT-HAL,rt_entry_add_msg_proc,2886: proto L2 bridge,len 48 prefix 06:d4:f2:00:00:cb/48 nh 2850 fpc0 RT-HAL,rt_entry_create,2414: failed to allocate memory for route entry These messages worry me. I have been looking into MVRP which seems like it will allow us to not need all 3500 VLANs trunked into the switches all the time, but will dynmicaly register VLANs as needed. Wondering peoples thoughts on MVRP, is this a good use case? Is it stable and reliable? thanks, ___ 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] Lab gear to mimic MX80?
ACX would do better, it uses same JUNOS build (for PowerPC) as MX80. Thanks Alex - Original Message - From: Morgan McLean wrx...@gmail.com To: juniper-nsp@puck.nether.net Sent: Friday, March 01, 2013 11:12 PM Subject: [j-nsp] Lab gear to mimic MX80? Hey everyone, I'd like to pick up a few pieces of gear to simulate our MX80's in production. We wouldn't necessarily need the same amount of memory, throughput etc just feature set and general config. I've been using SRX220's for everything up to now, but thats not always accurate to what I'd see on an MX box. Would it be safe to say I could pickup the relatively cheap J2350 boxes and stick the same version of JunOS on them and have a pretty similar experience? Not like the MX80 has any processing cards or anything special like the higher end MX boxes can take. -- Thanks, Morgan ___ 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 loop with OSPFv3 NSSA and external routes
Looks like R2 has 2 equal-cost Ext routes, both with metric-type 2. What happens if you redistribute on SW1 with metric-type 1? Also, what do your link metrics look like? Are they BW-related or just 1 for any link (LAG or single 1/10GE)? Lastly, what happens if R1 has no-nssa-abr configured? Thanks Alex - Original Message - From: Tore Anderson t...@fud.no To: Juniper List juniper-nsp@puck.nether.net Sent: Thursday, February 21, 2013 11:55 AM Subject: [j-nsp] Routing loop with OSPFv3 NSSA and external routes Hi list, I'm scratching my head over an OSPFv3 routing loop to an external NSSA destination that happens when extending the area to another router in the backbone. This is (hopefully) all the relevant parts of the currently (working) setup. The two routers R1 and R2 are MX-es running JUNOS 12.2R3, SW1 is an EX4200 VC running 10.4R6. 2001:db8::1/128 gets advertised to SW1 by a host using RIPng, and SW1 exports this route into OSPFv3. 2001:db8::1/128 | (RIPng-advertised) ~ | [SW1 - ID 192.0.2.40] | | (NSSA area 10.0.0.0) | | xe-1/2/0.5 [R2 - ID 192.0.2.4] | ae0.0 | xe-1/2/0.6 | | | (area 0) | (area 0) | | | ae0.0 | xe-1/2/0.6 [R1 - ID 192.0.2.5] On R2 I can see the external NSSA route appear fine: R2 show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface xe-1/2/0.5, NH-addr fe80::3 Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium ...and on R1 I can see that the ABR R2 translated it into a normal external route and advertised it into area 0: R1 show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface ae0.0, NH-addr fe80::2 NH-interface xe-1/2/0.6, NH-addr fe80::62:2 Area 0.0.0.0, Origin 192.0.2.4, Fwd NZ, Priority medium The problem occurs when I attempt to include R1 into area 10.0.0.0. This I do by adding ae0.0 on R1 and R2 into the area in secondary mode. My problem is that as soon as I do so, traffic to 2001:db8::1/128 starts to loop between R1 and R2. As expected, R1 now sees the type-7 LSA generated by SW1 (and readvertises it into area 0 since it's now an ABR): R1 run show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface ae0.0, NH-addr fe80::2 Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium R2, on the other hand, for seam prefers the area 0 external route that was generated by R1 over the NSSA route generated by SW1: R2 run show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface ae0.0, NH-addr fe80::1 NH-interface xe-1/2/0.6, NH-addr fe80::62:1 Area 0.0.0.0, Origin 192.0.2.5, Fwd NZ, Priority medium I have the exact same topology set up for IPv4/OSPFv3/RIPv2, and then R2 prefers the route it learned from SW1's Type-7 LSA within area 10.0.0.0, instead of the normal external route received from R1. I would have expected the same to happen with OSPFv3, but for some reason the priorities are the other way around. Anyone have an idea as to whether this is a bug or if I'm doing something wrong here? BR, -- Tore Anderson ___ 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] IPSec Tunnel between Remote office and main Office
http://www.juniper.net/techpubs/software/junos-security/junos-security10.2/junos-security-swconfig-security/topic-41894.html set security flow tcp-mss ipsec-vpn mss 1300 - should fix it. Thanks Alex - Original Message - From: Muhammad Atif Jauhar atif.jau...@gmail.com To: juniper-nsp@puck.nether.net Sent: Tuesday, February 19, 2013 3:25 PM Subject: Re: [j-nsp] IPSec Tunnel between Remote office and main Office Hi, One of our client has currently below topology to connect all remote sides to main office. Remote Site-1(SRX240) --E1- Router --GE- Main Office (SRX 650) | | | Remote Site-x(SRX240) --E1 Following are other part of configuration: 1. All devices running RIP because Router is very old and need extra support license for OSPF. 2. Route based IPSec tunnel is configured between both Remote site SRX240 and SRX650. 3. All E1 links on remote side and Ge link between SRX650 are in Untrust Zone 4. All st interfaces are in VPN Zone, LAN interfaces are in Trust Zone. 5. Policies are allowed between different sources and destination between VPN and Trust Zone. 6. Traffic is denied between Untrust and VPN/Trust Zone. Client want to remove Router from topology and connect of E1 links on SRX650. We have perform following steps to migrate one link for testing: 1. Remove E1 link from router and connect it to SRX650. 2. Put above E1 link in RIP and Untrust Zone. 3. Put Routing Policies E1 link in RIP to stop learning Trust subnets from E1 link. So that only routes will learn from St link. Only Ge interface IP is learned from E1 link. 3. We didn't change any VPN configuration on both side and IPSec tunnel is comes up and also traffic is passing. External interface in VPN Configuration on SRX650 still is Ge interface VPN IKE Gateway on Remote site is same Ge interface IP on SRX650. We observe following thing: 1. When we access remote firewall, session hanged sometime and also output of any command displayed slowly. 2. When we access remote firewall directly from main office SRX, session completely hanged, Once we put command of bigger output like request support information or show configuration etc. 3. If we access same way in step 2 for other remote firewalls there is no issue. Kindly let us know, there is any issue If we have Directly connected link but we are establishing IPSec tunnel with other Interface IP like Ge interface on SRX650. IKE Gateway on SRX650 for remote firewall is same E1 link Interface. Means on remote firewall IKE gateway is Ge interface of SRX650 and On SRX650 IKE Gateway is E1 link of remote firewall. Any way to troubleshoot session hanging and slowness. Regards, Muhammad Atif Jauhar (+966-56-00-04-985) ___ 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] Junos labeled-unicast announces unusable routes, certainly this is a bug
Probably not what you want to hear at the moment but it is working as designed. There is nothing in BGP RFCs which mandate that BGP-LU _must_ consult LDP/RSVP/LFIB etc before announcing routes. To force BGP-LU to consult LDP/RSVP and automatically advertise/withdraw routes matching LSP endpoints, use combination of: 1/ mpls traffic-engineering bgp-igp-both-ribs (installs LDP/RSVP routes in inet.0 and in inet.3) 2/ BGP-LU export policy which exports LDP/RSVP routes as well as own loopback (all of them are in inet.0 as a result of [1] above) 3/ resolve-vpn under BGP LU family which causes received BGP-LU routes to install in both inet.0 and inet.3, for inet-vpn NH resolution HTH Thanks Alex - Original Message - From: Jeff Wheeler j...@inconcepts.biz To: juniper-nsp juniper-nsp@puck.nether.net Sent: Monday, January 21, 2013 12:25 AM Subject: [j-nsp] Junos labeled-unicast announces unusable routes,certainly this is a bug Dear List, The process of raising a PR with JTAC generally makes me want to scream, so I thought I would post first, and perhaps some kind Juniper person can input a PR# without me having to reproduce the problem again and jump through twenty hoops to later be told working as designed. When configuring BGP labeled-unicast on Junos, you might think (like I hoped) that you could use LDP to create FECs and allocate labels, and then use those labels in your MP-BGP session. Unfortunately this does not work, and the basic reason is Junos BGP wants to allocate its own labels, and won't consult the LDP FEC table to see if any already exist for a given protocol next-hop which is being announced to the neighbor. Fine, so it wants to allocate its own labels. However, trying to avoid this behavior, I found it's pretty easy to get Junos to announce broken labeled-unicast routes that can never work, even though the receiving BGP speaker has no idea they are invalid. The receiver will just install the routes, forward traffic, and the traffic will get blackholed. This happens because Junos is trying to announce NLRI with no allocated labels (because layer-3 next-hop is not self) and it can't announce them when labeled-unicast is configured, because the documentation is wrong, and you canNOT actually configure both AFI=1 SAFI=1 and AFI=1 SAFI=4 on the same BGP session. It simply does not work, and the Juniper documentation on this subject is incorrect. So what happens is, the announcing router knows it wants to announce a prefix, but it has no label stack for it, won't allocate one, and instead it just puts in label 1048575, or 2^20-1. This label is not in the LFIB, so when that router receives packets with that label, it doesn't pop the label and do a layer-3 look-up. Instead, it just discards the packets. Worse than that, the announcing router's `show route advertising-protocol bgp neighbor` output is incorrect. It shows no label, even though it really is sending a label stack with 2^20-1. You have to go over to the receiving router to find this out. So this combination of documentation bugs and ridiculous Junos ability to announce labeled BGP routes that it knows for sure are invalid, is quite foolish, to say nothing of the fact that it won't just use FECs you already created using LDP. :/ Anyway, if you ever get labeled BGP routes with label 2^20-1, this might be why. Hopefully some kind Juniper folks will be willing to file some bugs on this for me, because I don't have a week to fight with JTAC about it. It is, however, very easy to reproduce the problem. :-) Thanks -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts ___ 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] L2ALM errors on SRX?
You can disable his process if you so desire: aarseniev@dale show chassis hardware Hardware inventory: Item Version Part number Serial number Description Chassis SRX210h-p-m Routing Engine REV 30 750-024364 RE-SRX210H-P-M FPC 0FPC PIC 0 2xGE,6xFE,1x3G,2xFXS,2xFXO ANNEX REV 04 711-028410 Power Supply 0 aarseniev@dale edit Entering configuration mode [edit] aarseniev@dale# run show system processes extensive | grep l2a 1066 root 1 760 14160K 4956K select 0 31:10 0.00% l2ald [edit] aarseniev@dale# set system processes l2-learning disable [edit] aarseniev@dale# commit commit complete [edit] aarseniev@dale# run show system processes extensive | grep l2a [edit] aarseniev@dale# - Original Message - From: Julien Goodwin jgood...@studio442.com.au To: juniper-nsp juniper-nsp@puck.nether.net Sent: Friday, January 18, 2013 12:53 PM Subject: [j-nsp] L2ALM errors on SRX? ___ 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] Error while validating a JunOS
Jinstall validates both current _AND_ rescue config. Check if you have rescue config set and if yes then overwrite it with current config request system config rescue save HTH Thanks Alex - Original Message - From: Ali Sumsam ali+juniper...@eintellego.net To: juniper-nsp@puck.nether.net Sent: Friday, November 30, 2012 1:25 AM Subject: [j-nsp] Error while validating a JunOS Hi, I have a brand new MX5 router for one of my customers. The only configuration I have on this router is 1, one login name and password 2, IP address on FXP0 3, telnet and ftp service. I have uploaded Junos jinstall-ppc-11.2R5.4-export-signed.tgz, which is the recommended one for MX5 on juniper site. When i try to validate this JunOS, it gives me following error. mgd: error: configuration check-out failed Validation failed WARNING: Current configuration not compatible with /var/tmp/jinstall-ppc-11.2R5.4-export-signed.tgz Any suggestion. Can I just ignore this error and live with it? Regards, *Ali Sumsam CCIE* *Network Engineer - Level 3* eintellego Pty Ltd a...@eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)410 603 531 facebook.com/eintellego PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM ___ 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] Error while validating a JunOS
Jinstall validates both current _AND_ rescue config. Check if you have rescue config set and if yes then overwrite it with current config request system config rescue save HTH Thanks Alex - Original Message - From: Ali Sumsam ali+juniper...@eintellego.net To: juniper-nsp@puck.nether.net Sent: Friday, November 30, 2012 1:25 AM Subject: [j-nsp] Error while validating a JunOS Hi, I have a brand new MX5 router for one of my customers. The only configuration I have on this router is 1, one login name and password 2, IP address on FXP0 3, telnet and ftp service. I have uploaded Junos jinstall-ppc-11.2R5.4-export-signed.tgz, which is the recommended one for MX5 on juniper site. When i try to validate this JunOS, it gives me following error. mgd: error: configuration check-out failed Validation failed WARNING: Current configuration not compatible with /var/tmp/jinstall-ppc-11.2R5.4-export-signed.tgz Any suggestion. Can I just ignore this error and live with it? Regards, *Ali Sumsam CCIE* *Network Engineer - Level 3* eintellego Pty Ltd a...@eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)410 603 531 facebook.com/eintellego PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM ___ 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] DHCP interface as next hop
- Original Message - From: sth...@nethelp.no I can understand the choice of not including this functionality. Juniper can avoid the well known of problem of pointing a default route at an Ethernet interface, leading to an ARP for every new/unknown destination. There is a recent post on this board describing this exact problem with ARP for every new/unknown destination https://puck.nether.net/pipermail/juniper-nsp/2012-November/024826.html However, the original issue - 0/0 pointing to DHCP default-router - is scriptable easily enough in SLAX. Should you go this route, make sure your provider has ARP policer in place to withstand a routing loop in your network :-) HTH Rgds Alex ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Fw: L2 Circuits accross domains
You should have remote loopbacks also redistributed into LDP (if your
transport label is from LDP).
In JUNOS, this does not happen by default, you must have LDP egress-policy
for this to occur. By default, LDP announces only primary lo0.0 IP@.
Absent this, your L2circuits would show OL error (no outgoing label).
Before you ask, this is totally different to CSCO IOS which announces all
routes (bar BGP ones) as LDP FECs.
HTH
Rgds
Alex
- Original Message -
From: Peter Nyamukusa peternyamuk...@yahoo.com
To: juniper-nsp@puck.nether.net
Cc: pe...@nyamukusa.com
Sent: Tuesday, November 20, 2012 7:46 AM
Subject: [j-nsp] Fw: L2 Circuits accross domains
- Forwarded Message -
From: Peter Nyamukusa peternyamuk...@yahoo.com
To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Sent: Tuesday, November 20, 2012 9:33 AM
Subject: L2 Circuits accross domains
Hi Folks,
I have an exsisting L3 / L2 MPLS network with Cisco ASR on the Core as PE
router and Junper routers as PE router, i have been running l2circuits
sucessfully for some time now with out any problems using the below configs
on my PEs, I am running IS-IS as my IGP and BGP
[edit protocols l2circuit]
peter@xxx-PE1# show
}
neighbor 41.x.x.1 {
interface ge-0/0/2.2001 {
virtual-circuit-id 2001;
description XYZ L2;
no-control-word;
ignore-mtu-mismatch;
[edit interfaces ge-0/0/2]
peter@xxx-PE1# show
description Customers L2 Circuits;
vlan-tagging;
encapsulation vlan-ccc;
unit 2001 {
description XYZ L2;
encapsulation vlan-ccc;
vlan-id 2001;
}
Neighbor: 41.x.x.2
Interface Type St Time last up # Up trans
ge-0/0/2.2001(vc 2001) rmt Up Nov 13 15:29:31 2012 1
Remote PE: 41.x.x.2, Negotiated control-word: No
Incoming label: 299776, Outgoing label: 299776
Local interface: ge-0/0/2.2001, Status: Up, Encapsulation:
VLAN
Description: XYZ L2
Neighbor: 41.x.x.x.1
Interface Type St Time last up # Up trans
ge-0/0/2.2101(vc 2101) rmt Up Nov 13 15:29:28 2012 1
Remote PE: 41.x.x.1, Negotiated control-word: Yes (Null)
Incoming label: 299792, Outgoing label: 333568
Local interface: ge-0/0/2.2101, Status: Up, Encapsulation: VLAN
Description: ABC L2 - ANY POP
Now I am trying to extend these L2 circuits to anther MPLS Domain where we
have direct Gigabit fibre connection I am using the same concept and
establish ospf peering on the ASBR router with the remote ASN and
redistributed my IGP so my loopbacks are seen by the PEs on both sides of
the domains and establish ldp peering how ever the l2circuit is not coming
up any help is appriciated as I have been working on this more than 24hrs
and think that i am now a bit clouded
peter@yyy-BR1# run show l2circuit connections (ASN 1234)
Layer-2 Circuit Connections:
Legend for connection status (St)
EI -- encapsulation invalid NP -- interface h/w not present
MM -- mtu mismatch Dn -- down
EM -- encapsulation mismatch VC-Dn -- Virtual
circuit Down
CM -- control-word mismatch Up -- operational
VM -- vlan id mismatch CF -- Call admission control failure
OL -- no outgoing label IB -- TDM incompatible bitrate
NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration
BK -- Backup Connection ST -- Standby Connection
CB -- rcvd cell-bundle size bad XX -- unknown
Legend for interface status
Up -- operational
Dn -- down
Neighbor: 5.1.1.2
Interface Type St Time last up # Up trans
ge-0/0/0.2900(vc 2900) rmt OL
peter@xxx-PE1# run show l2circuit connections (ASN4321)
Layer-2 Circuit Connections:
Legend for connection status (St)
EI -- encapsulation invalid NP -- interface h/w not present
MM -- mtu mismatch Dn -- down
EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down
CM -- control-word mismatch Up -- operational
VM -- vlan id mismatch CF -- Call admission control failure
OL -- no outgoing label IB -- TDM incompatible bitrate
NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration
BK -- Backup Connection ST -- Standby Connection
CB -- rcvd
cell-bundle size bad XX -- unknown
Legend for interface status
Up -- operational
Dn -- down
Neighbor: 5.1.1.1
Interface Type St Time last up # Up trans
ge-0/0/2.2900(vc 2900) rmt OL
---
| Kind Regards, |
| Peter
Nyamukusa |
| MCSE-2000/2003, CCIP, CCDP, CCVP, CCNP, |
| JNCIS-ent, JNCIS-er, JNCIS-Sec, JNCIA-Ex, Linux+, A+ |
---
___
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] Fw: L2 Circuits accross domains
This is not enough.
You must have LDP egress-policy and include these loopbacks there too
https://www.juniper.net/techpubs/software/junos/junos93/swconfig-mpls-apps/configuring-the-ldp-egress-policy.html
HTH
Thanks
Alex
- Original Message -
From: Peter Nyamukusa
To: Alex Arseniev ; juniper-nsp@puck.nether.net
Sent: Tuesday, November 20, 2012 11:07 AM
Subject: Re: [j-nsp] Fw: L2 Circuits accross domains
Thanks Alex,
I had already redistibuted all my loopback into my IGP and all were reachable
| Kind Regards, |
| Peter Nyamukusa |
| MCSE-2000/2003, CCNP, CCIP, CCDP, CCVP, |
| JNICIS-ent, JNCIS-er, JNCIS-Sec, JNCIA-Ex, Linux+, A+ |
-
--
From: Alex Arseniev alex.arsen...@gmail.com
To: Peter Nyamukusa peternyamuk...@yahoo.com; juniper-nsp@puck.nether.net
Sent: Tuesday, November 20, 2012 12:28 PM
Subject: Re: [j-nsp] Fw: L2 Circuits accross domains
You should have remote loopbacks also redistributed into LDP (if your
transport label is from LDP).
In JUNOS, this does not happen by default, you must have LDP egress-policy
for this to occur. By default, LDP announces only primary lo0.0 IP@.
Absent this, your L2circuits would show OL error (no outgoing label).
Before you ask, this is totally different to CSCO IOS which announces all
routes (bar BGP ones) as LDP FECs.
HTH
Rgds
Alex
- Original Message - From: Peter Nyamukusa
peternyamuk...@yahoo.com
To: juniper-nsp@puck.nether.net
Cc: pe...@nyamukusa.com
Sent: Tuesday, November 20, 2012 7:46 AM
Subject: [j-nsp] Fw: L2 Circuits accross domains
- Forwarded Message -
From: Peter Nyamukusa peternyamuk...@yahoo.com
To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
Sent: Tuesday, November 20, 2012 9:33 AM
Subject: L2 Circuits accross domains
Hi Folks,
I have an exsisting L3 / L2 MPLS network with Cisco ASR on the Core as PE
router and Junper routers as PE router, i have been running l2circuits
sucessfully for some time now with out any problems using the below configs on
my PEs, I am running IS-IS as my IGP and BGP
[edit protocols l2circuit]
peter@xxx-PE1# show
}
neighbor 41.x.x.1 {
interface ge-0/0/2.2001 {
virtual-circuit-id 2001;
description XYZ L2;
no-control-word;
ignore-mtu-mismatch;
[edit interfaces ge-0/0/2]
peter@xxx-PE1# show
description Customers L2 Circuits;
vlan-tagging;
encapsulation vlan-ccc;
unit 2001 {
description XYZ L2;
encapsulation vlan-ccc;
vlan-id 2001;
}
Neighbor: 41.x.x.2
Interface Type St Time last up # Up trans
ge-0/0/2.2001(vc 2001) rmt Up Nov 13 15:29:31 2012 1
Remote PE: 41.x.x.2, Negotiated control-word: No
Incoming label: 299776, Outgoing label: 299776
Local interface: ge-0/0/2.2001, Status: Up, Encapsulation:
VLAN
Description: XYZ L2
Neighbor: 41.x.x.x.1
Interface Type St Time last up # Up trans
ge-0/0/2.2101(vc 2101) rmt Up Nov 13 15:29:28 2012 1
Remote PE: 41.x.x.1, Negotiated control-word: Yes (Null)
Incoming label: 299792, Outgoing label: 333568
Local interface: ge-0/0/2.2101, Status: Up, Encapsulation: VLAN
Description: ABC L2 - ANY POP
Now I am trying to extend these L2 circuits to anther MPLS Domain where we
have direct Gigabit fibre connection I am using the same concept and establish
ospf peering on the ASBR router with the remote ASN and redistributed my IGP so
my loopbacks are seen by the PEs on both sides of the domains and establish ldp
peering how ever the l2circuit is not coming up any help is appriciated as I
have been working on this more than 24hrs and think that i am now a bit clouded
peter@yyy-BR1# run show l2circuit connections (ASN 1234)
Layer-2 Circuit Connections:
Legend for connection status (St)
EI -- encapsulation invalid NP -- interface h/w not present
MM -- mtu mismatch Dn -- down
EM -- encapsulation mismatch VC-Dn -- Virtual
circuit Down
CM -- control-word mismatch Up -- operational
VM -- vlan id mismatch CF -- Call admission control failure
OL -- no outgoing label IB -- TDM incompatible bitrate
NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration
BK -- Backup Connection ST -- Standby Connection
CB -- rcvd cell-bundle size bad XX -- unknown
Legend for interface status
Up -- operational
Dn -- down
Neighbor: 5.1.1.2
Interface Type St Time last up # Up trans
ge-0/0/0.2900(vc 2900) rmt OL
peter@xxx-PE1# run show l2circuit connections (ASN4321)
Layer-2 Circuit Connections:
Legend for connection status (St)
EI -- encapsulation invalid NP -- interface h/w not present
MM -- mtu mismatch Dn -- down
EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down
CM -- control-word mismatch Up -- operational
Re: [j-nsp] Strange VRRP problem -- question about restarting process
Well, that's fairly straightforward - either (1) VRRP on master [J] stopped sending or (2) CSCO switches stopped forwarding VRRP hellos, or (3) backup [J] drops incoming VRRP hellos. You can verify (1) by using monitor traffic interface blah no-resolve size . (2) could be verified with SPAN/RSPAN (3) cannot be verified with monitor traffic interface _if_ there is an input FW filter. monitor traffic interface a.k.a. tcpdump does not capture packets dropped by FW filter. Which begs a question - do you have an input FW filter on VRRP interfaces or lo0 and if yes, do you allow protocol vrrp as well as AH/proto 51 and have you added/changed VRRP auth type recently? Proto 51 is used when VRRP MD5 auth is configured. In any case, I'd suggest to configure a FW filter to log/syslog incoming VRRP packets (dst.ip 224.0.0.18/32) on backup [J]. HTH Rgds Alex - Original Message - From: John Neiberger jneiber...@gmail.com To: juniper-nsp@puck.nether.net Sent: Friday, November 02, 2012 3:37 PM Subject: [j-nsp] Strange VRRP problem -- question about restarting process We have a very odd problem that we've been dealing with for a couple of weeks. JTAC is involved but we have not come to a resolution yet. The gist of the problem is that we have two MX960s and we're running VRRP on multiple interfaces with different Cisco switches in between each pair of Juniper interfaces. [J] - [C][C]-- [J] The switches are just layer two and we're running VRRP on the routers. The problem is that one day, three of the interfaces on the backup router suddenly stopped receiving VRRP messages from its peer. JTAC seems to think that the Cisco switches just suddenly stopped forwarding VRRP messages to the backup router, but that makes zero sense unless some bizarre issue just happened to occur on multiple unrelated switches at exactly the same moment. I'm still leaning toward a problem on the router. Which leads me to my question. What is the risk of restarting the VRRP process? I see we have soft and graceful as options. Both sound fairly low-risk. I'm tempted to just restart the process on the backup router to see if that fixes the problem. What do you think? Thanks, John ___ 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] SRX: rate-limiting source NAT sources
You can limit flows per individual source IP (not NAT ports) using UTM https://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/configuration-statement/security-edit-limit.html You'll need a UTM license. And if you are doing NAT on branch SRX, UTM is supported only on high-memory branch SRX boxes. Thanks Alex - Original Message - From: Jonathan Lassoff j...@thejof.com To: juniper-nsp@puck.nether.net Sent: Monday, October 29, 2012 9:55 PM Subject: [j-nsp] SRX: rate-limiting source NAT sources So, I'm working on tuning an SRX deployment and am wondering if something is possible. This deployment is doing a lot of source NAT for a wide variety of endpoints as they egress out to the Internet. Pretty vanilla configuration. Specific sources are mapped via NAT rules to specific egress IPs (for IP filtering in some places, outside of the SRXes in question). And once in a while, some endpoint will have a legitimate need to open up *many* connections (and then NAT states) that pass over this SRX deployment. Unfortunately, the rate of connection establishment relative to the application timeouts means that these heavy users can use up all of the ephemeral ports, blocking new flows from becoming established. We've been playing a bit of whack-a-mole, assigning more IP space to the various source NAT pools, but would like to find a more proper solution. So, my question is this: is there any mechanism anyone knows of to rate-limit or block-past-a-threshold a source NAT source if it starts making too many connections? I don't see anything obvious in the SRX documentation, so I figured I'd ask here for pointers. Right now, it's way to easy for one bad actor (malicious or benevolent) to max out a source NAT pool. Cheers, jof ___ 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] Juniper Services Question ?
The service-filter directs matching packets to a particular service-set. So in a sense, service-filter is executed first because match happens on ingress interface, and service-set execution happens inside AS|MS-PIC|DPC when matching packets have entered the ingress interface+crossed the forwarding plane. HTH Rgds Alex - Original Message - From: Vasanth R S rsvasanth...@gmail.com To: juniper-nsp@puck.nether.net Sent: Friday, October 26, 2012 12:22 PM Subject: [j-nsp] Juniper Services Question ? If you have service-set and service-filter, which one will get serviced first ? set interfaces ge-1/0/0 unit 1 family inet service input service-set ss-nat service-filter nat-exclude-input set interfaces ge-1/1/0 unit 2 family inet service input service-set ss-nat service-filter nat-exclude-input set firewall family inet service-filter nat-exclude-input term rfc1918 from destination-address 10.0.0.0/8 set firewall family inet service-filter nat-exclude-input term rfc1918 from destination-address 172.16.0.0/12 set firewall family inet service-filter nat-exclude-input term rfc1918 from destination-address 192.168.0.0/16 set firewall family inet service-filter nat-exclude-input term rfc1918 then skip set firewall family inet service-filter nat-exclude-input term public from destination-prefix-list -public-nat-exclude set firewall family inet service-filter nat-exclude-input term public then skip set firewall family inet service-filter nat-exclude-input term default then service -- Regards, Vasanth R S ___ 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] port mirror to multiple ports on MX80 in inet6
Have you tried PM instances?
- Original Message -
From: Paul Vlaar p...@vlaar.net
To: Alex Arseniev alex.arsen...@gmail.com
Cc: juniper-nsp@puck.nether.net
Sent: Friday, October 19, 2012 9:49 AM
Subject: Re: [j-nsp] port mirror to multiple ports on MX80 in inet6
Alex,
On 19/10/12 7:33 AM, Alex Arseniev wrote:
You could do cascaded PM. In a nutshell:
1/ port-mirror original packet, send the original packet on its way
2/ send the COPY into a loop (cable loop or looped tunnel)
3/ take the looped COPY and mirror it once again, creating 2nd copy.
4/ send 1st copy and 2nd copy on their respective ways.
The problem I see there is how do you configure the [ port-mirroring
family inet6 ] section with a different output interface on the second
run once you hit the port-mirror statement in the firewall rule.
forwarding-options {
port-mirroring {
family inet6 {
output {
interface ge-1/3/2.0 {
next-hop fdb5:1281:f3cf:c7c4::2;
}
no-filter-check;
}
}
}
}
Can you perhaps send me some example config on how to do this?
What strikes me is that the lack of next-hop-groups for inet6 feels like
a software limitation.
~paul
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX sending thousands of VRRP packets per second
Multicast loop/L2 loop in the network? - Original Message - From: Saba Sumsam saba+j...@eintellego.net To: juniper-nsp@puck.nether.net Sent: Thursday, October 18, 2012 5:18 AM Subject: [j-nsp] SRX sending thousands of VRRP packets per second Hi, We have two SRX 100s configured for VRRP; where SRX-A is the primary and SRX-B is the backup. I have noticed a great deal of VRRP packets being sent out - I have a capture of 50k packets being sent out in the first 7 seconds I monitored. The packets being sent out on SRX-B is lesser than on SRX-A but still is a lot more than what would be expected. Both devices are configured with the default vrrp advertisement interval of 1 sec. Any thoughts on why I would be seeing so much traffic? Regards, Saba ___ 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] port mirror to multiple ports on MX80 in inet6
You could do cascaded PM. In a nutshell:
1/ port-mirror original packet, send the original packet on its way
2/ send the COPY into a loop (cable loop or looped tunnel)
3/ take the looped COPY and mirror it once again, creating 2nd copy.
4/ send 1st copy and 2nd copy on their respective ways.
HTH
Rgds
Alex
- Original Message -
From: Paul Vlaar p...@vlaar.net
To: juniper-nsp@puck.nether.net
Sent: Thursday, October 18, 2012 11:45 PM
Subject: [j-nsp] port mirror to multiple ports on MX80 in inet6
Hi, I've currently successfully gotten port mirroring setup to more than
one port, using the following config:
port-mirroring {
family inet {
output {
next-hop-group default-collect;
}
}
next-hop-group default-collect {
group-type inet;
interface ge-1/3/2.0 {
next-hop 192.168.10.2;
}
interface ge-1/3/5.0 {
next-hop 192.168.20.2;
}
}
router show configuration interfaces ge-1/3/2
unit 0 {
family inet {
address 192.168.10.1/30 {
arp 192.168.10.2 mac 00:1b:21:86:a2:92;
}
}
family inet6 {
address fdb5:1281:f3cf:c7c4::1/64 {
ndp fdb5:1281:f3cf:c7c4::2 mac 00:1b:21:86:a2:92;
}
}
}
router show configuration interfaces ge-1/3/5
unit 0 {
family inet {
address 192.168.20.1/30 {
arp 192.168.20.2 mac 00:1b:21:86:a3:9a;
}
}
family inet6 {
address fd3d:122a:8541:ecb5::1/64 {
ndp fd3d:122a:8541:ecb5::2 mac 00:1b:21:86:a2:93;
}
}
}
This works very nicely, I see traffic at both measurement hosts. I would
like to do the same for IPv6, but there's no next-hop-group setting
available:
[edit forwarding-options port-mirroring family inet6 output]
router# set ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
interfaceInterfaces through which to send sampled traffic
no-filter-check Do not check for filters on port-mirroring interface
[edit forwarding-options port-mirroring family inet6 output]
This limitation is actually mentioned in the documentation, here:
http://www.juniper.net/techpubs/en_US/junos12.2/topics/usage-guidelines/services-configuring-port-mirroring.html
Port mirroring supports up to 16 next hops, but there is no next-hop
group support for inet6.
However I was wondering perhaps someone knows if there's a trick to this
using filter based forwarding? I can't really figure out how from the
examples given.
This is an MX80 on JunOS 11.2R3.3
Thanks!
~paul
___
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] DHCP option 82 under forwarding-options helpers bootpconfiguration
Hello there,
forwarding-options helpers bootp is not DHCP relay, it is a different
feature although they both use same socket.
To insert option 82, you need forwarding-option dhcp-relay feature which
requires a license.
BOOTP helper and dhcp-relay|dhcp-local-server cannot be configured together
( see above).
dhcp-relay and dhcp-local-server can be configured together in different
VRs/VRFs.
Thanks
Alex
- Original Message -
From: Martin T m4rtn...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Monday, September 17, 2012 1:15 PM
Subject: [j-nsp] DHCP option 82 under forwarding-options helpers
bootpconfiguration
Hi,
JUNOS(10.4R9.2 at M10i) supports DHCP relay agent information option
configuration under forwarding-options helpers bootp. However,
despite the configuration, DHCP messages received by DHCP server do
not have option 82 present. For example I made such configuration:
root@labM10i show configuration forwarding-options helpers bootp
dhcp-option82 {
circuit-id {
use-vlan-id;
}
remote-id {
use-string test;
}
vendor-id {
test;
}
}
description helpers bootp test;
server 10.10.10.1;
interface {
ge-1/2/0.5;
}
root@labM10i
..and executed dhclient in a broadcast domain associated with
interface ge-1/2/0.5. Packet capture results on a 10.10.10.1 DHCP
server can be seen here: http://cloudshark.org/captures/e963f493caf8
As you can see, there is no option 82 added.
Is it possible to add DHCP option 82 to messages forwarded to DHCP
server under forwarding-options helpers bootp configuration? Or is
this possible only with dhcp-relay? Latter would make more sense as
this option should be strictly DHCP
option(http://tools.ietf.org/html/rfc3046) not the BOOTP option?
regards,
martin
___
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] Fwd: mx480 to mx240 port channel ae
What JUNOS version and linecard HW?
interface-mode trunk is supported on Trio starting from 11.1.
Thanks
Alex
- Original Message -
From: Mohammad Khalil eng.m...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Thursday, July 19, 2012 6:48 AM
Subject: [j-nsp] Fwd: mx480 to mx240 port channel ae
-- Forwarded message --
From: Mohammad Khalil eng.m...@gmail.com
Date: Wed, Jul 18, 2012 at 11:45 AM
Subject: mx480 to mx240 port channel ae
To: juniper-nsp@puck.nether.net
Hi all , I have mx480 and mx240 routers
I tried to connect them via ether channel (port aggregation) , but there
was remarkable packet loss
CR04# show interfaces ae1
flexible-vlan-tagging;
mtu 1600;
encapsulation flexible-ethernet-services;
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family bridge {
interface-mode trunk;
}
}
unit 10 {
vlan-id 10;
family inet {
address 10.0.0.17/30;
Any ideas ?
Thanks
BR,
Mohammad
___
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] Destination Class Accounting: counters are zero
Hello there,
This might help
http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/source-class-usage-guidelines-solution.html
quote
A source or destination class is applied to a packet only once during the
routing table lookup. When a network prefix matches a class-usage policy,
SCU is assigned to packets first; DCU is assigned only if SCU has not been
assigned. Be careful when using both class types, since misconfiguration can
result in uncounted packets.
/quote
Rgds
Alex
- Original Message -
From: Alexander Shikoff minot...@crete.org.ua
To: juniper-nsp@puck.nether.net
Sent: Tuesday, May 15, 2012 9:25 AM
Subject: [j-nsp] Destination Class Accounting: counters are zero
Hello List,
I have MX240 router (10.0 R4.7) with two peering links and two upstream
links.
I need separate accounting of customer's traffic: to/from upstreams and
to/from peerings.
I configured an SCU input accounting on peering and upstream links,
DCU and SCU output accounting on customer's link:
minot...@br1-gdr.ki# show interfaces ae0 unit 753
vlan-id 753;
family inet {
accounting {
source-class-usage {
output;
}
destination-class-usage;
}
no-redirects;
filter {
output bw-100M-U;
}
address 109.68.41.133/30;
}
Then I applied export policy to forwarding table, now every route
has an assigned class, for example:
minot...@br1-gdr.ki# run show route juniper.net table Salt extensive |
match class
Destination class: to-Upstream
Source class: from-Upstream
Now let's check extensive information about customer's interface:
minot...@br1-gdr.ki# run show interfaces ae0.753 extensive
Logical interface ae0.753 (Index 97) (SNMP ifIndex 197) (Generation 168)
Description: Downstream: Digital Screens Kurenevka
Flags: SNMP-Traps 0x4000 VLAN-Tag [ 0x8100.753 ] Encapsulation: ENET2
StatisticsPacketspps Bytes bps
Bundle:
Input :1355645712 10824 1744298393787125788672
Output: 676249013 3535 50730352637 1954232
Link:
ge-2/0/5.753
Input :1355645712 10824 1744298393787125788672
Output: 676249013 3535 50730352637 1954232
Marker Statistics: Marker Rx Resp Tx Unknown Rx Illegal Rx
ge-2/0/5.753 0 000
Protocol inet, MTU: 1500, Generation: 198, Route table: 6
Flags: No-Redirects, DCU, SCU-out
PacketsBytes
Destination class(packet-per-second)(bits-per-second)
to-Other 1966210997515326
( 9) (
4129)
to-Peering 904424 1216778711
( 2932) (
32529971)
to-Upstream00
( 0) (
0)
PacketsBytes
Source class (packet-per-second)(bits-per-second)
from-Other88128 5568059
( 0) (
53)
from-Peering 534506 37189579
( 1136) (
664770)
from-Upstream16017 1066310
( 97) (
49421)
Output Filters: bw-100M-U-ae0.753-o,
Addresses, Flags: Is-Preferred Is-Primary
Destination: 109.68.41.132/30, Local: 109.68.41.133, Broadcast:
109.68.41.135, Generation: 177
Protocol multiservice, MTU: Unlimited, Generation: 199, Route table: 6
Policer: Input: __default_arp_policer__
Why 'to-Upstream' counters are zeroes?
Thanks in advance!
--
MINO-RIPE
___
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] CGN ob MX5?
CGN used to be known/also known as Large Scale NAT (LSN) Compare this http://tools.ietf.org/html/draft-nishitani-cgn-01 and this http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-05 Same IETF draft, different versions. - Original Message - From: Xu Hu jstuxuhu0...@gmail.com To: Saku Ytti s...@ytti.fi Cc: juniper-nsp@puck.nether.net Sent: Friday, April 13, 2012 8:20 AM Subject: Re: [j-nsp] CGN ob MX5? Recently heard so many times about CGN, but i still don't understand what is the difference between NAT and CGN, can any expert explain what's the CGN. 2012/4/12 Saku Ytti s...@ytti.fi On (2012-04-12 16:31 +0200), Matthias Brumm wrote: I would like to know, if no, some or all implementations of CGN will be working on a MX5? This seems in realms of possibility (1ipv6 statically to 1ipv4) for trio. But if you know you will need CGN I would assume that MX5 will never get it, this way you'll avoid disappointment and possibly need for another box while waiting for needed feature to appear. NAPT (port based, nto1) is not possible as far as I understand on trio, then you'd need some service slot in the behind, which also I would assume never to exist when making purchase decision. -- ++ytti ___ 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX supports other variants of j-Flow except IPFIX
v5: either RE-based or Service PIC|MSDPC-based v8: either RE-based or Service PIC|MSDPC-based v9: only Service PIC|MSDPC-based. I repeat: v9 is _only_ Service PIC|MSDPC-based. No chance of v9 flow sampling/exporting on Routing Engine. HTH Rgds Alex - Original Message - From: Arun Kumar narain.a...@gmail.com To: juniper-nsp@puck.nether.net Sent: Wednesday, April 11, 2012 8:32 AM Subject: [j-nsp] Juniper MX supports other variants of j-Flow except IPFIX Hi Juniper NSP, Would like to know whether Juniper MX series router support other variants of jflow except IP FIX. Flow collector that i m evaluating does not support IPFIX v10 (inline-jflow) which MX supports. So just wanted to check what other variants of jflow that can be supported. thanks Arun ___ 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] Flow analysis question
show services accounting flow-detail http://www.juniper.net/techpubs/en_US/junos11.4/topics/reference/command-summary/show-services-accounting-flow-detail.html Please read carefully, especially the caveats. HTH Alex - Original Message - From: Michael Smith mksm...@mac.com To: juniper-nsp@puck.nether.net Sent: Sunday, April 08, 2012 6:34 PM Subject: [j-nsp] Flow analysis question Hello: Is it possible on the MX series to look at the flow logs real time? In Cisco, you can attach to the linecard and do a 'sho ip cache flow' that shows you the Netflow data. I'm looking for something similar on the MX. Thanks, Mike ___ 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] Loopback interface and rib-groups
You don't have to do that with lo0 interface routes in JUNOS.
Configure lo0.nonzero-unit-number with same IP, put it in Salt RI and it
will work.
HTH
Rgds
Alex
- Original Message -
From: Alexander Shikoff minot...@crete.org.ua
To: juniper-nsp@puck.nether.net
Sent: Sunday, March 25, 2012 3:39 AM
Subject: [j-nsp] Loopback interface and rib-groups
Hello List,
I have lo0.0 interface in default routing table :
minot...@br1-gdr.ki# show interfaces lo0
unit 0 {
family inet {
address 109.68.40.32/32;
}
}
minot...@br1-gdr.ki# run show route 109.68.40.32/32 table inet.0
inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
109.68.40.32/32*[Direct/0] 00:38:51
via lo0.0
I export interface route to other routing instance:
[edit]
minot...@br1-gdr.ki# show routing-options interface-routes
rib-group inet rg-Main2Salt;
[edit]
minot...@br1-gdr.ki# show routing-options rib-groups rg-Main2Salt
import-rib [ inet.0 Salt.inet.0 ];
[edit]
minot...@br1-gdr.ki# run show route 109.68.40.32/32 table Salt
Salt.inet.0: 399123 destinations, 407025 routes (399121 active, 0
holddown, 2 hidden)
+ = Active Route, - = Last Active, * = Both
109.68.40.32/32*[Direct/0] 00:33:52
via lo0.0
But when I'm trying to ping 109.68.40.32 via interface in Salt instance
I get replies not from 109.68.40.32:
/home/minotaurping 109.68.40.32
PING 109.68.40.32 (109.68.40.32): 56 data bytes
64 bytes from 109.68.40.225: icmp_seq=0 ttl=61 time=0.933 ms
64 bytes from 109.68.40.225: icmp_seq=1 ttl=61 time=0.904 ms
^C
--- 109.68.40.32 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.904/0.919/0.933/0.014 ms
109.68.40.225 is an adress of interface in Salt instance:
minot...@br1-gdr.ki# show interfaces xe-1/3/0
unit 0 {
description Core;
family inet {
no-redirects;
address 109.68.40.225/29;
}
}
What's wrong? Thanks in advance!
--
MINO-RIPE
___
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] proxy arp C vs J
Did you check what MACs are used in 1st, 2nd and 3rd time? Specifically MAC OUIs. I suspect this is a side effect of having C-J in the same broadcast domain. Basically, when J-interface ARPs for a connected host, _AND_ if C has a specific route to that host/32, the C will answer with own MAC. I have seen this myself many times and I suggest to disable proxy-arp on C to get rid of this behavior. HTH Thanks Alex - Original Message - From: biwa net biwa...@gmail.com To: juniper-nsp@puck.nether.net Sent: Monday, February 06, 2012 7:57 PM Subject: Re: [j-nsp] proxy arp C vs J Forgot to add we are running MX80 on Junos 11.2 On 6 February 2012 19:56, biwa net biwa...@gmail.com wrote: Hi Guys We are experiencing some issues in one of our client sites, Basically we migrate from a Cisco to a Juniper MX80, and since there has been some issues, mainly we are seeing IP addresses being shared by 2-3 mac address, to be precise , mac address being rewritten , ie: one IP is being seen on the Juniper owned by 3 different mac address within one hour ( the 1st mac address is being re-writen by the 2nd one and then 2nd by the 3rd mac). This is causing a lot of users not having any kind of internet connectivity.When we rollback to the Cisco device , this issue does not occur. After investigation we can safely eliminates the DHCP server being the cause of issue (, also proved when Cisco is roll back in the topology), The config of the Cisco is fairly simple and is almost 99.99% than the one being copied over to the Juniper. One thing we notice is that both Cisco and Juniper has proxy-arp configured on some of the interface, and we are planning in our next maintenance to disable it. my question is: is the proxy-arp behavior in Juniper slightly different than the Cisco ? thanks for your inputs ___ 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] GRE packet fragmentation on j-series
My understanding is that GRE fragmentation should occur if egress interface
MTU is GRE pkt size.
For GRE reassembly, you need IDP policy, this means high memory SRX model.
IDP license is not needed.
Rgds
Alex
- Original Message -
From: Lukasz Martyniak lmartyn...@man.szczecin.pl
To: juniper-nsp@puck.nether.net
Sent: Tuesday, January 24, 2012 2:04 PM
Subject: [j-nsp] GRE packet fragmentation on j-series
Hi all
I have some problem with gre tunnels. I need to fragment packages in
tunnel. I run gre between two jseries (junos 10.4R6) and lunch MPLS on it.
The problem looks like that packages with MTU above 1476 are not
fragmented/reassembled and are dropped.
interfaces gr-0/0/0
unit 10 {
clear-dont-fragment-bit;
description Tulne to r1-lab;
tunnel {
source 10.200.0.1;
destination 10.200.0.2;
allow-fragmentation;
path-mtu-discovery;
}
family inet {
mtu 1500;
address 100.100.100.1/30;
}
family mpls {
}
}
Have someone have similar problem ? is there a simple way to fix this ?
Best Lukasz
___
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] PPTP VPN through NAT on M10i
PPTP ALG is supported from JUNOS 11.2R1
GRE is not supported with nat source dynamic
HTH
Rgds
Alex
- Original Message -
From: Jo Rhett jrh...@netconsonance.com
To: juniper-nsp@puck.nether.net
Sent: Tuesday, January 17, 2012 3:19 AM
Subject: [j-nsp] PPTP VPN through NAT on M10i
I've got a problem with NAT on an M10i with Junos 10.4. Simple PNAP
interface, works fine for TCP and UDP. Doesn't work for PPTP or IPSEC. Way
back in my mind I remember something about having to create a second nat
rule without port mapping, but its not working. I'm pretty sure I'm
forgetting something here. Can someone spare a 2x4 and clue me over the
head?
---yes, I know that the filters in the configuration below aren't active.
Here's the configuration now:
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
ge-0/1/0 {
unit 0 {
family inet {
service {
input {
service-set NAT;
}
output {
service-set NAT;
}
}
address 192.168.2.1/24;
}
}
}
sp-0/3/0 {
unit 0 {
family inet;
}
}
….
firewall {
filter UNTRUST-IN {
term ICMP {
from {
destination-address {
192.168.2.1/4;
}
protocol icmp;
}
then accept;
}
term EVERYTHING-ELSE {
then {
discard;
}
}
}
filter TRUST-OUT {
term IPOUT {
from {
source-address {
192.168.1.0/24;
}
destination-address {
0.0.0.0/0;
}
}
then accept;
}
}
}
services {
service-set NAT {
nat-rules Outbound;
interface-service {
service-interface sp-0/3/0.0;
}
}
nat {
pool NATPOOL {
address 192.168.2.3/32
port {
automatic;
}
}
pool GRE-NATPOOL {
address 192.168.2.3/32
}
rule Outbound {
match-direction output;
term PPTP_VPNs {
from {
source-address {
192.168.1.0/24;
}
applications GRE-PPTP;
}
then {
translated {
source-pool GRE-NATPOOL;
translation-type {
source dynamic;
}
}
}
}
term Else {
from {
source-address {
192.168.1.0/24;
}
}
then {
translated {
source-pool NATPOOL;
translation-type {
source dynamic;
}
}
}
}
}
}
adaptive-services-pics {
traceoptions {
flag all;
}
}
}
applications {
application GRE-PPTP {
protocol gre;
}
}
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source and
other randomness
___
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] Junos EX - mcsnoopd high cpu
Answer 1: edit set system processes multicast-snooping disable commit HTH Rgds Alex - Original Message - From: pkc mls pkc_...@yahoo.fr To: juniper-nsp@puck.nether.net Sent: Thursday, December 22, 2011 8:27 AM Subject: [j-nsp] Junos EX - mcsnoopd high cpu Hi all, I have an issue with ex3200 devices on which mcsnoopd consumes a lot of cpu. I'm searching for mcsnoopd info everywhere, but it looks like there is not much about this, except message logs. The ex switches run the latest 10.4 release, and if you have a look at the releases notes there are already some fixes relates to mcsnoopd. question 1 : (maybe silly, but I ask anyway) Is it possible to stop the mcsnoopd on a device, if there is no multicast at all on the network ? (ie the switches are used as regular layer 2 switches with vlans). question 2 : is it possible to debug mcsnoopd ? thanks. ___ 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] Junos OSPF Inter-Area Routes !
Active Backbone Detection http://www.juniper.net/techpubs/en_US/junos9.6/information-products/topic-collections/config-guide-routing/routing-configuring-ospf-areas.html Active backbone detection enables transit through an area border router with no active backbone connection. HTH Rgds Alex - Original Message - From: vaibhava varma svaibh...@gmail.com To: juniper-nsp@puck.nether.net Sent: Friday, December 09, 2011 8:43 AM Subject: [j-nsp] Junos OSPF Inter-Area Routes ! Dear All Recently I was working on a scenario in OSPF for checking the use of Backbone Area 0 for Inter-Area communication and I was surprised to see that 2 Non-Backbone areas were able to exchange inter-area routes without any Area 0 configured. Well the same thing did not work in Cisco which was the expected behavior per documentations. Topology was simple R1-Area3-R2-Area2-R1 Can anyone help to understand the above behavior in Junos. -- Regards Varma ___ 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
[j-nsp] Fwd: Point-to-point Ethernet interfaces
Florian, Perhaps a silly question - are these interfaces on the same router? If yes what you are trying to accomplish is possible with unnumbered Ethernet interfaces and forwarding-table-filter to prevent hosts talking to each other. Start here http://www.juniper.net/techpubs/software/junos/junos84/swconfig84-network-interfaces/id-10413973.html#id-10413973 and please read the restrictions http://www.juniper.net/techpubs/software/junos/junos84/swconfig84-network-interfaces/jN212B7.html#jN212B7 Forwarding table filter http://www.juniper.net/techpubs/software/junos/junos84/swconfig84-policy/id-10824476.html#id-10824476 Rgds Alex On 15/11/2007, Florian Weimer [EMAIL PROTECTED] wrote: Is it possible to put an Ethernet interface into point-to-point with JUNOS 8.4? Basically, the setup I want is: ge-0/0/0 (172.16.1.1) - hostA (172.16.1.2) ge-0/0/1 (172.16.1.1) - hostB ( 172.16.1.3, 172.16.1.4) ge-0/0/2.102 (172.16.1.1, 802.1q tagged) - hostC (172.16.1.5) The router uses ARP to obtain MAC addresses for the host IP addresses, and answers ARP requests for the 172.16.1.1 address. Proper interface/VLAN separation must be maintained. The rationale is address space conservation and easier documentation. /30 routes don't work in hostB's case, where more than one address is required. (So we need something between 4 and 6 as much IP addresses as strictly necessary.) I haven't checked if /31 interfaces work, but in any case, they require host-specific default gateways, making documentation slightly more difficult. Any suggestions? I know that the desired setup isn't strictly allowed by the standards, but it works quite well with various systems, and the address space savings are quite nice. -- Florian Weimer[EMAIL PROTECTED] BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ 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
