Re: [j-nsp] Help with BGP as-path regex
Hi Alex,
That looks like what I want, thanks!
Here's a brief test I tried:
Policy definitions:
as-path 3257_originate "^3257+.*";
policy-statement as_3257_import {
term gtt {
from {
protocol bgp;
as-path 3257_originate;
}
then accept;
}
term reject-all {
then reject;
}
}
policy-statement as_3257_import-test {
term gtt {
from {
protocol bgp;
as-path 3257_originate;
as-path-unique-count 2 orlower;
}
then accept;
}
term reject-all {
then reject;
}
}
This route has 3 unique AS hops and includes prepending, it should pass the
as_3257_import policy, but fail the as_3257_import-test policy
# run show route 1.32.208.0/24
inet.0: 760463 destinations, 1010435 routes (760460 active, 2 holddown, 1
hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
1.32.208.0/24 *[BGP/170] 1d 19:59:15, MED 1347, localpref 100
AS path: 3257 7473 7473 7473 64050 64050 I,
validation-state: unverified
As expected, the route passes as_3257_import policy test. This policy is
not using the as-path-unique-count configuration knob:
# run test policy as_3257_import 1.32.208.0/24
inet.0: 760502 destinations, 1010269 routes (760495 active, 6 holddown, 1
hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
1.32.208.0/24 *[BGP/170] 1d 20:02:52, MED 1347, localpref 100
AS path: 3257 7473 7473 7473 64050 64050 I,
validation-state: unverified
Policy as_3257_import: 1 prefix accepted, 0 prefix rejected
As expected, the same route fails the test using the policy that includes
the as-path-unique-count knob with value 2 orlower. The route has too many
unique AS hops:
# run test policy as_3257_import-test 1.32.208.0/24
Policy as_3257_import-test: 0 prefix accepted, 1 prefix rejected
Now we update unique count to 3:
policy-statement as_3257_import-test {
term gtt {
from {
protocol bgp;
as-path 3257_originate;
as-path-unique-count 3 orlower;
}
then accept;
}
term reject-all {
then reject;
}
}
Now the test policy succeeds as expected:
# run test policy as_3257_import-test 1.32.208.0/24
inet.0: 760500 destinations, 1010273 routes (760405 active, 94 holddown, 1
hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
1.32.208.0/24 *[BGP/170] 1d 20:03:02, MED 1347, localpref 100
AS path: 3257 7473 7473 7473 64050 64050 I,
validation-state: unverified
Policy as_3257_import-test: 1 prefix accepted, 0 prefix rejected
kind regards,
-andy
On Thu, Sep 12, 2019 at 9:20 PM Alexander Arseniev
wrote:
> Hello,
>
> Does this help?
>
>
> https://www.juniper.net/documentation/en_US/junos/information-products/topic-collections/release-notes/16.1/m-mx-t-series-toc.html
> <https://www.juniper.net/documentation/en_US/junos/information-products/topic-collections/release-notes/16.1/m-mx-t-series-toc.html#jd0e11155>
>
> Support for unique AS path count ( MX Series)—Starting with Junos OS
> Release 16.1R4, you can configure a routing policy to determine the number
> of unique autonomous systems (ASs) present in the AS path. The unique AS
> path count helps determine whether a given AS is present in the AS path
> multiple times, typically as prepended ASs. In earlier Junos releases it
> was not possible to implement this counting behavior using the as-path regular
> expression policy. This feature permits the user to configure a policy
> based on the number of AS hops between the route originator and receiver.
> This feature ignores ASs in the as-path that are confederation ASs, such
> as confed_seq and confed_set.
>
> To configure AS path count, include the as-path-unique-count count (equal
> | orhigher | orlower) configuration statement at the [edit policy-options
> policy-statement policy_name from] hierarchy level.
>
>
> Thanks
>
> Alex
>
>
> On 13/09/2019 00:18, Andy Litzinger wrote:
>
> Hi All,
> I thought this would be in a cookbook somewhere but I can't find it. Is
> there a way to write an as-path regex so it will match a providers ASN
> (e.g. 1234) one or more times and then 1 or 2 more ASNs zero or more
> times? I'm hoping to be able to account for AS prepending.
>
> I'm an Enterprise network and one of my upstream ISPs is sending me full
> routes + default. I want to filter the routes down to networks that are
> directly connected or at most 2 hops away from my ISP, but also allow for
> AS prepending. It's the prepending that is tripping me up or else I think
> this would suffice: "^1234+ .{0,2}"
>
> I think with cisco you can do this with backreferences, but Junos doesn't
> seem to support those.
>
> TI
[j-nsp] Help with BGP as-path regex
Hi All,
I thought this would be in a cookbook somewhere but I can't find it. Is
there a way to write an as-path regex so it will match a providers ASN
(e.g. 1234) one or more times and then 1 or 2 more ASNs zero or more
times? I'm hoping to be able to account for AS prepending.
I'm an Enterprise network and one of my upstream ISPs is sending me full
routes + default. I want to filter the routes down to networks that are
directly connected or at most 2 hops away from my ISP, but also allow for
AS prepending. It's the prepending that is tripping me up or else I think
this would suffice: "^1234+ .{0,2}"
I think with cisco you can do this with backreferences, but Junos doesn't
seem to support those.
TIA,
-andy
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] minimum permissions for napalm/pyez user
Hello! We are attempting to use Napalm which I understand is using pyez/netconf over ssh under the hood. We can get things to work with a full admin level user, but we'd like to pare down the access to only what is required. right now we are specifically hitting an issue where when we run the napalm open() method with our restricted user it fails because it's trying to drop into the shell and run the command "xml-mode netconf need-trailer" . We verified this by logging the interactive commands at our router and comparing what was run with an admin user vs our restricted user. We get a the following error: >>> import napalm_junos >>> mx_router = napalm_junos.JunOSDriver(hostname="ip.address",username="my_restricted_user",password="my_pass") >>> mx_router.open() Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.7/site-packages/napalm_junos/junos.py", line 106, in open self.device.open() File "/usr/local/lib/python2.7/site-packages/jnpr/junos/device.py", line 1291, in open raise cnx_err jnpr.junos.exception.ConnectError: ConnectError(host: ip.address, msg: Unexpected session close IN_BUFFER: ` error: unknown command: xml-mode error: permission denied: netconf `) TIA! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Firewall filter with apply-path
Hi Ross, I essentially use the example straight from here: http://forums.juniper.net/t5/Day-One-Books/Day-One-Book-Securing-the-Routin g-Engine-on-M-MX-and-T-Series/ba-p/92276 and they work great. HTH, -andy On 7/27/15, 2:45 PM, juniper-nsp on behalf of Ross Halliday juniper-nsp-boun...@puck.nether.net on behalf of ross.halli...@wtccommunications.ca wrote: Hi list, Would someone be so kind as to apply a working example configuration to protect the RE using apply-path to generate prefix lists? I *THINK* I have the actual apply-path part working, as show configuration ... inheritance shows what should be in there, but when I set the firewall filter on lo0.0 it doesn't match any packets and everything is just dropped. :( I am new to JUNOS so a sanitized working example would be absolutely fantastic. I'm running MX104s on 13.3R4.6, if that matters. Thanks! Ross ___ 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] sip calls through srx fail after approx 15 min
So far the culprit appears to have been the NAT setup. Contrary to my
understanding a source NAT with a 1:1 mapping does still seem to use PAT.
AFAICT there is no way to disable that for a single source NAT rule, only
for all source NAT. This presumes that the 'security nat source
port-randomization disable' knob has the effect of disabling PAT on a 1:1
source nat. I'm not able to test that as I'm relying on other source NATs
that I don't want to interrupt. Anyway, I updated my config to use static
NAT and we were immediately able to hold a test call for far longer than
15m (we let it go to 50m before we ended it).
We'll continue to test and monitor and I'll report back here if we have
issues. thanks to everyone for their help!
-andy
On Thu, May 28, 2015 at 12:10 PM, Andy Litzinger
andy.litzinger.li...@gmail.com wrote:
Hi Majdi,
So are you saying that the sip alg can not be disabled? Or that I won't
be able to get sip to work through the SRX without using the alg? Thanks
for bringing up NAT, I did forget to mention our NAT setup. The provider
requires that NAT and not PAT is used. I've accomplished that by source
NAT for the pbx (perhaps I should switch to static NAT?).
Presuming our provider has configured their SIP gateway to work properly
with NAT and presuming I've configured NAT properly, are you saying there
is no way make this work on the SRX with the sip alg disabled?
here is my NAT setup:
srx01 show configuration security nat
source {
pool pool-avaya-public-nat {
address {
x.x.x.x/32;
}
}
rule-set internal-to-net {
from zone internal;
to zone external;
rule avaya-pbx-to-net {
match {
source-address-name avaya-pbx;
}
then {
source-nat {
pool {
pool-avaya-public-nat;
}
}
}
}
proxy-arp {
interface ge-0/0/0.0 {
address {
x.x.x.x/32;
}
}
}
thanks,
-andy
On Thu, May 28, 2015 at 11:41 AM, Majdi S. Abbas m...@latt.net wrote:
On Thu, May 28, 2015 at 11:36:20AM -0700, Andy Litzinger wrote:
We're configuring a new sip setup with a phone vendor. The provider
pbx
sits inside our network and makes connections out through our SRX to the
provider sip gateways. Calls are working, but seem to drop at or near
the
15 minute mark. The provider is sure that it's a setting on the SRX.
The
one issue we may have found is that it seems we might be having some
trouble truly turning off the sip alg which is a requirement of the
provider. Despite our best efforts I continue to see sessions when I
issue
the command 'show security flow session application sip'. Firstly, am I
correct in assuming that if I see a session here that it indicates the
sip
alg is being used?
SIP is not NAT friendly, so you are using the ALG. Now, as far
as tuning that ALG, start with adjusting the timeout beyond the 3600s
that most people use as their default:
applications {
application junos-sip {
term t1 inactivity-timeout 7200;
}
}
If you also experience one-way audio problems, you may need the
following as well:
security {
alg {
sip {
application-screen {
unknown-message {
permit-nat-applied;
permit-routed;
}
}
}
}
}
Cheers,
--msa
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] sip calls through srx fail after approx 15 min
Hi Majdi,
So are you saying that the sip alg can not be disabled? Or that I won't be
able to get sip to work through the SRX without using the alg? Thanks for
bringing up NAT, I did forget to mention our NAT setup. The provider
requires that NAT and not PAT is used. I've accomplished that by source
NAT for the pbx (perhaps I should switch to static NAT?).
Presuming our provider has configured their SIP gateway to work properly
with NAT and presuming I've configured NAT properly, are you saying there
is no way make this work on the SRX with the sip alg disabled?
here is my NAT setup:
srx01 show configuration security nat
source {
pool pool-avaya-public-nat {
address {
x.x.x.x/32;
}
}
rule-set internal-to-net {
from zone internal;
to zone external;
rule avaya-pbx-to-net {
match {
source-address-name avaya-pbx;
}
then {
source-nat {
pool {
pool-avaya-public-nat;
}
}
}
}
proxy-arp {
interface ge-0/0/0.0 {
address {
x.x.x.x/32;
}
}
}
thanks,
-andy
On Thu, May 28, 2015 at 11:41 AM, Majdi S. Abbas m...@latt.net wrote:
On Thu, May 28, 2015 at 11:36:20AM -0700, Andy Litzinger wrote:
We're configuring a new sip setup with a phone vendor. The provider
pbx
sits inside our network and makes connections out through our SRX to the
provider sip gateways. Calls are working, but seem to drop at or near
the
15 minute mark. The provider is sure that it's a setting on the SRX.
The
one issue we may have found is that it seems we might be having some
trouble truly turning off the sip alg which is a requirement of the
provider. Despite our best efforts I continue to see sessions when I
issue
the command 'show security flow session application sip'. Firstly, am I
correct in assuming that if I see a session here that it indicates the
sip
alg is being used?
SIP is not NAT friendly, so you are using the ALG. Now, as far
as tuning that ALG, start with adjusting the timeout beyond the 3600s
that most people use as their default:
applications {
application junos-sip {
term t1 inactivity-timeout 7200;
}
}
If you also experience one-way audio problems, you may need the
following as well:
security {
alg {
sip {
application-screen {
unknown-message {
permit-nat-applied;
permit-routed;
}
}
}
}
}
Cheers,
--msa
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] sip calls through srx fail after approx 15 min
Hi all,
We're configuring a new sip setup with a phone vendor. The provider pbx
sits inside our network and makes connections out through our SRX to the
provider sip gateways. Calls are working, but seem to drop at or near the
15 minute mark. The provider is sure that it's a setting on the SRX. The
one issue we may have found is that it seems we might be having some
trouble truly turning off the sip alg which is a requirement of the
provider. Despite our best efforts I continue to see sessions when I issue
the command 'show security flow session application sip'. Firstly, am I
correct in assuming that if I see a session here that it indicates the sip
alg is being used?
srx01 show security flow session application sip
Session ID: 45838, Policy name: avaya-pbx-to-sip-ports/36, Timeout: 60,
Valid
In: 172.x.x.x/5060 -- x.x.x.x/5060;udp, If: ge-0/0/1.24, Pkts: 3, Bytes:
2146
Out: x.x.x.x/5060 -- x.x.x.x/9675;udp, If: ge-0/0/0.0, Pkts: 3, Bytes:
1626
Total sessions: 1
the sip alg counters(show security alg sip counters) aren't increasing, and
turning on sip traceoptions isn't logging anything but the existence of the
flow in the session table makes me suspicious.
I've attempted to disable use of the alg by doing the following:
* disabling the alg globaly
set security alg sip disable
* create application groups that don't reference the alg
* referenced those applications in the security policy that allows the pbx
to contact the remote sip gateway
Is my sip alg truly disabled? If so, any ideas why calls might be dropping
at the 15m mark? The phone doesn't actually disconnect, but the call stops
working.
many thanks,
-andy
Here's some relevant config snippets:
srx01 show security alg status
ALG Status :
DNS : Enabled
FTP : Enabled
H323 : Enabled
MGCP : Enabled
MSRPC: Enabled
PPTP : Enabled
RSH : Enabled
RTSP : Enabled
SCCP : Enabled
SIP : Disabled
snip
srx01 show configuration applications application my-sip-tcp
protocol tcp;
destination-port 5060-5070;
srx01 show configuration applications application my-sip-udp
protocol udp;
destination-port 5060-5070;
srx01 show configuration security policies from-zone internal to-zone
external policy avaya-pbx-to-sip-ports
match {
source-address avaya-pbx;
destination-address sip-gateway;
application [ my-sip-udp my-sip-tcp ];
}
then {
permit;
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 JFlow Setup
The flow configuration is working as posted- i was testing this in a
legacy setup and forgot there was another firewall in the path between my
mx80s and my flow collector.
thanks all for the help!
-andy
On Thu, Jan 15, 2015 at 9:44 AM, Andy Litzinger
andy.litzinger.li...@gmail.com wrote:
Hi Scott and all,
can you give an example of what i might have to open? I have a
reject-all and log statement at the end of my lo0.0 filter and I don't see
any matches toward my flow-server ip. I'm also don't understand why an
input filter on the loopback would impact outbound traffic to my
flow-server?
I forgot to mentions, but I'm running 13.3R4.6
I am running a tcpdump on my flow-server and no packets have arrived. It
seems to me that flows are being captured and exported, even with the
default template settings:
# run show services accounting flow inline-jflow
Flow information
TFEB Slot: 0
Flow Packets: 5805, Flow Bytes: 3941343
Active Flows: 4, Total Flows: 3907
Flows Exported: 3457, Flow Packets Exported: 3453
Flows Inactive Timed Out: 3204, Flows Active Timed Out: 699
let a few seconds pass
# run show services accounting flow inline-jflow
Flow information
TFEB Slot: 0
Flow Packets: 5806, Flow Bytes: 3942763
Active Flows: 2, Total Flows: 3907
Flows Exported: 3458, Flow Packets Exported: 3454
Flows Inactive Timed Out: 3206, Flows Active Timed Out: 699
regards,
-andy
On Thu, Jan 15, 2015 at 6:51 AM, Scott Granados sc...@granados-llc.net
wrote:
You will definitely have to poke a hole in your firewall on your
loopback. Also, make sure the loopback is part of the main routing
instance not in another grouting instance, your source until very recent
releases has to be in the global table. Use TCPDump to make sure that flow
packets are reaching your collector as well for testing.
On Jan 15, 2015, at 12:18 AM, Andy Litzinger
andy.litzin...@theplatform.com wrote:
Yes I do. Sounds like I need to pole a hole?
On Jan 14, 2015, at 6:14 PM, Eduardo Schoedler lis...@esds.com.br
wrote:
Do you have a firewall in your loopback?
--
Eduardo
Em quarta-feira, 14 de janeiro de 2015, Andy Litzinger
andy.litzinger.li...@gmail.com escreveu:
Levi,
did you get this working? My MX80 appears to be collecting flows,
but I
don't see any output to my flow server. The server ip is reachable
from my
MX 80.
# show chassis
snip
tfeb {
slot 0 {
sampling-instance tp-sampling-instance;
}
}
# show forwarding-options sampling
traceoptions {
file ipfix.log size 10k;
}
instance {
tp-sampling-instance {
input {
rate 1000;
}
family inet {
output {
flow-server my flow server {
port 2055;
version-ipfix {
template {
ipfix-ipv4-template;
}
}
}
inline-jflow {
source-address my loopback;
}
}
}
}
}
# show services
flow-monitoring {
version-ipfix {
template ipfix-ipv4-template {
ipv4-template;
}
}
}
# show interfaces ge-1/0/0
snip
unit 0 {
family inet {
sampling {
input;
}
address isp-uplink-ip;
}
}
# run show services accounting status inline-jflow
Status information
TFEB Slot: 0
IPV4 export format: Version-IPFIX, IPV6 export format: Not set
VPLS export format: Not set
IPv4 Route Record Count: 516479, IPv6 Route Record Count: 4
Route Record Count: 516483, AS Record Count: 143756
Route-Records Set: Yes, Config Set: Yes
# run show services accounting flow inline-jflow
Flow information
TFEB Slot: 0
Flow Packets: 1445, Flow Bytes: 1419455
Active Flows: 22, Total Flows: 935
Flows Exported: 764, Flow Packets Exported: 752
Flows Inactive Timed Out: 623, Flows Active Timed Out: 290
regards,
-andy
--
Eduardo Schoedler
___
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] MX80 JFlow Setup
Levi,
did you get this working? My MX80 appears to be collecting flows, but I
don't see any output to my flow server. The server ip is reachable from my
MX 80.
# show chassis
snip
tfeb {
slot 0 {
sampling-instance tp-sampling-instance;
}
}
# show forwarding-options sampling
traceoptions {
file ipfix.log size 10k;
}
instance {
tp-sampling-instance {
input {
rate 1000;
}
family inet {
output {
flow-server my flow server {
port 2055;
version-ipfix {
template {
ipfix-ipv4-template;
}
}
}
inline-jflow {
source-address my loopback;
}
}
}
}
}
# show services
flow-monitoring {
version-ipfix {
template ipfix-ipv4-template {
ipv4-template;
}
}
}
# show interfaces ge-1/0/0
snip
unit 0 {
family inet {
sampling {
input;
}
address isp-uplink-ip;
}
}
# run show services accounting status inline-jflow
Status information
TFEB Slot: 0
IPV4 export format: Version-IPFIX, IPV6 export format: Not set
VPLS export format: Not set
IPv4 Route Record Count: 516479, IPv6 Route Record Count: 4
Route Record Count: 516483, AS Record Count: 143756
Route-Records Set: Yes, Config Set: Yes
# run show services accounting flow inline-jflow
Flow information
TFEB Slot: 0
Flow Packets: 1445, Flow Bytes: 1419455
Active Flows: 22, Total Flows: 935
Flows Exported: 764, Flow Packets Exported: 752
Flows Inactive Timed Out: 623, Flows Active Timed Out: 290
regards,
-andy
On Tue, Dec 23, 2014 at 9:16 AM, Levi Pederson
levipeder...@mankatonetworks.net wrote:
All,
Trying to get an MX80 to output Flow to an external collector. I've been
reading several pieces of documentation and I keep getting differing views
and opinions on how this is supposed to be done. I'm looking for the
simplest option right now and if I need to expand I can move to more
detailed processes after
I'm currently using the following
[edit chassis]
- tfeb {
- slot 0 {
- sampling-instance calix;
- }
- }
[edit]
- forwarding-options {
- sampling {
- instance {
- calix {
- input {
- rate 50;
- }
- family inet {
- output {
- flow-server [ipaddress] {
- port 2058;
- version-ipfix {
- template {
- ipv4;
- }
- }
- }
- inline-jflow {
- source-address [ipaddress];
- }
- }
- }
- }
- }
- }
- }
- services {
- flow-monitoring {
- version-ipfix {
- template ipv4 {
- flow-active-timeout 60;
- flow-inactive-timeout 70;
- template-refresh-rate {
- seconds 30;
- }
- option-refresh-rate {
- seconds 30;
- }
- ipv4-template;
- }
- }
- }
- }
Edited for Anonymity.
Thank you,
.
*Levi Pederson*
Mankato Networks LLC
cell | 612.481.0769
work | 612.787.7392
levipeder...@mankatonetworks.net
___
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] MX80 JFlow Setup
Yes I do. Sounds like I need to pole a hole?
On Jan 14, 2015, at 6:14 PM, Eduardo Schoedler lis...@esds.com.br wrote:
Do you have a firewall in your loopback?
--
Eduardo
Em quarta-feira, 14 de janeiro de 2015, Andy Litzinger
andy.litzinger.li...@gmail.com escreveu:
Levi,
did you get this working? My MX80 appears to be collecting flows, but I
don't see any output to my flow server. The server ip is reachable from my
MX 80.
# show chassis
snip
tfeb {
slot 0 {
sampling-instance tp-sampling-instance;
}
}
# show forwarding-options sampling
traceoptions {
file ipfix.log size 10k;
}
instance {
tp-sampling-instance {
input {
rate 1000;
}
family inet {
output {
flow-server my flow server {
port 2055;
version-ipfix {
template {
ipfix-ipv4-template;
}
}
}
inline-jflow {
source-address my loopback;
}
}
}
}
}
# show services
flow-monitoring {
version-ipfix {
template ipfix-ipv4-template {
ipv4-template;
}
}
}
# show interfaces ge-1/0/0
snip
unit 0 {
family inet {
sampling {
input;
}
address isp-uplink-ip;
}
}
# run show services accounting status inline-jflow
Status information
TFEB Slot: 0
IPV4 export format: Version-IPFIX, IPV6 export format: Not set
VPLS export format: Not set
IPv4 Route Record Count: 516479, IPv6 Route Record Count: 4
Route Record Count: 516483, AS Record Count: 143756
Route-Records Set: Yes, Config Set: Yes
# run show services accounting flow inline-jflow
Flow information
TFEB Slot: 0
Flow Packets: 1445, Flow Bytes: 1419455
Active Flows: 22, Total Flows: 935
Flows Exported: 764, Flow Packets Exported: 752
Flows Inactive Timed Out: 623, Flows Active Timed Out: 290
regards,
-andy
--
Eduardo Schoedler
___
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] controlling the source IP for the Dns Proxy feature
Hello,
is anyone out there using the dns-proxy feature for the branch SRX? Are
there any clever tricks for specifying the source address the SRX uses to
query name servers? It does not appear to be a config option.
with the default config it appears to use the IP of the outbound
interface. If I add the config statement 'set system default address
selection' i can influence it to use the lo0.0 address, which can solve my
issue, but not in a way i prefer.
my exact problem is the following:
I have an SRX 220H in a remote office. It has an trust and untrust zone.
users sit on the trust zone and receive dhcp from the SRX and use the SRX
as their default gateway and dns server. There is a policy based vpn that
connects from the untrust zone to our corp HQ. I have the dns-proxy config
set up so that if a dns request is going to an intranet zone, e.g.
corp.example.com, then it should use DNS servers that live across the
tunnel in our corp HQ. If they are looking up anything else, they use
google dns servers.
here's the relevant config:
dns-proxy {
interface {
interface facing users;
}
default-domain * {
forwarders {
8.8.8.8;
8.8.4.4;
}
}
default-domain corp.example.com {
forwarders {
corp hq name server1;
corp hq name server 2;
}
}
}
the problem is without the 'default address selection' set the SRX tries to
use the untrust interface IP as the source IP to query our corp HQ name
servers, but the traffic doesn't enter the tunnel because it doesn't match
the vpn policy. And I can't change the policy to allow it because the
untrust interface IP is the endpoint of the tunnel. It looks like the
source zone of the dns query is junos-host- is it possible maybe to set up
a junos-host zone to untrust zone NAT when going to corp-hq IP space?
or is there another clever solution?
thanks!
-andy
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] controlling the source IP for the Dns Proxy feature
I'd happily use route-based vpns if they are supported in my use case.
Based on Kbs and internet lore, it seemed policy based was the best bet
for stability.
My two tunnel endpoint devices are the SRX and a Cisco ASA.
On the SRX side I've got a single subnet but on the ASA side I've got two
subnets. I would happily use a simple policy on the ASA side like 'permit
ip any SRX side IP subnet SRX side mask' if i was confident I wasn't
going to have squirrely issues with connectivity.
What do you think?
-andy
On 10/15/14 3:22 PM, Ben Dale bd...@comlinx.com.au wrote:
Hi Andy,
I have come across this exact issue using the feature.
There was a good reason why we didn't use default address selection that
escapes me just now, but I had a slight advantage in that I was using
route-based VPNs, so I was able to number the st0 interface with a /32
from the corporate range and source my queries from there.
Unfortunately policy-based VPNs are extremely limiting when it comes to
things like this. I can't think of too many scenarios where I'd even use
them any more. If you don't have too many sites, I'd seriously consider
migrating them across.
Cheers,
Ben
On 16 Oct 2014, at 1:28 am, Andy Litzinger
andy.litzinger.li...@gmail.com wrote:
Hello,
is anyone out there using the dns-proxy feature for the branch SRX? Are
there any clever tricks for specifying the source address the SRX uses
to
query name servers? It does not appear to be a config option.
with the default config it appears to use the IP of the outbound
interface. If I add the config statement 'set system default address
selection' i can influence it to use the lo0.0 address, which can solve
my
issue, but not in a way i prefer.
my exact problem is the following:
I have an SRX 220H in a remote office. It has an trust and untrust zone.
users sit on the trust zone and receive dhcp from the SRX and use the
SRX
as their default gateway and dns server. There is a policy based vpn
that
connects from the untrust zone to our corp HQ. I have the dns-proxy
config
set up so that if a dns request is going to an intranet zone, e.g.
corp.example.com, then it should use DNS servers that live across the
tunnel in our corp HQ. If they are looking up anything else, they use
google dns servers.
here's the relevant config:
dns-proxy {
interface {
interface facing users;
}
default-domain * {
forwarders {
8.8.8.8;
8.8.4.4;
}
}
default-domain corp.example.com {
forwarders {
corp hq name server1;
corp hq name server 2;
}
}
}
the problem is without the 'default address selection' set the SRX
tries to
use the untrust interface IP as the source IP to query our corp HQ name
servers, but the traffic doesn't enter the tunnel because it doesn't
match
the vpn policy. And I can't change the policy to allow it because the
untrust interface IP is the endpoint of the tunnel. It looks like the
source zone of the dns query is junos-host- is it possible maybe to set
up
a junos-host zone to untrust zone NAT when going to corp-hq IP space?
or is there another clever solution?
thanks!
-andy
___
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] controlling the source IP for the Dns Proxy feature
I'm running 12.1X44-D40.2 right now (had to run newer 12.1X code to even
use the dns-proxy feature :) ). I'll give X46-D10 a look; the
traffic-selctors looks pretty interesting.
As far as your comment regarding widening the crypto-map- that's what i
was implying with my example acl- basically widening it on the cisco side
to include every IP subnet ('any'). Not sure if that's allowed.
Either way it looks like i've got some good options to try.
Thank you!
-andy
On 10/15/14 3:50 PM, Ben Dale bd...@comlinx.com.au wrote:
I've certainly had no issue with stability using route-based VPN.
As far as multiple subnet (proxy-id / traffic selectors) support, as of
12.1X46-D10 this is now native in Junos -
http://kb.juniper.net/InfoCenter/index?page=contentid=KB28820
and is dead simple to configure.
If you're a little gun shy on 12.1X code and are still running
old-faithful builds like 11.4RLate, then there are a couple of options:
- If your subnets are contiguous, just widen the mask to include them in
a single crypto-map on the Cisco side (even if that means widening the
mask a LOT)
- If your subnets are arbitrarily selected from different RFC1918 blocks
(DOH!), then create separate P2 bindings for each subnet:
http://kb.juniper.net/InfoCenter/index?page=contentid=KB20543
just be aware that this will only work if the multiple subnets are on the
Cisco side (which seems to be true in your case)
There are a few other hacks out there using FBF as well. J-NET has some
good material:
http://forums.juniper.net/t5/SRX-Services-Gateway/SRX-multiple-proxy-ID-on
-route-based-VPN-with-multiple-local/td-p/172002/page/2
Cheers,
Ben
On 16 Oct 2014, at 8:35 am, Andy Litzinger
andy.litzin...@theplatform.com wrote:
I'd happily use route-based vpns if they are supported in my use case.
Based on Kbs and internet lore, it seemed policy based was the best bet
for stability.
My two tunnel endpoint devices are the SRX and a Cisco ASA.
On the SRX side I've got a single subnet but on the ASA side I've got
two
subnets. I would happily use a simple policy on the ASA side like
'permit
ip any SRX side IP subnet SRX side mask' if i was confident I wasn't
going to have squirrely issues with connectivity.
What do you think?
-andy
On 10/15/14 3:22 PM, Ben Dale bd...@comlinx.com.au wrote:
Hi Andy,
I have come across this exact issue using the feature.
There was a good reason why we didn't use default address selection
that
escapes me just now, but I had a slight advantage in that I was using
route-based VPNs, so I was able to number the st0 interface with a /32
from the corporate range and source my queries from there.
Unfortunately policy-based VPNs are extremely limiting when it comes to
things like this. I can't think of too many scenarios where I'd even
use
them any more. If you don't have too many sites, I'd seriously
consider
migrating them across.
Cheers,
Ben
On 16 Oct 2014, at 1:28 am, Andy Litzinger
andy.litzinger.li...@gmail.com wrote:
Hello,
is anyone out there using the dns-proxy feature for the branch SRX?
Are
there any clever tricks for specifying the source address the SRX uses
to
query name servers? It does not appear to be a config option.
with the default config it appears to use the IP of the outbound
interface. If I add the config statement 'set system default address
selection' i can influence it to use the lo0.0 address, which can
solve
my
issue, but not in a way i prefer.
my exact problem is the following:
I have an SRX 220H in a remote office. It has an trust and untrust
zone.
users sit on the trust zone and receive dhcp from the SRX and use the
SRX
as their default gateway and dns server. There is a policy based vpn
that
connects from the untrust zone to our corp HQ. I have the dns-proxy
config
set up so that if a dns request is going to an intranet zone, e.g.
corp.example.com, then it should use DNS servers that live across the
tunnel in our corp HQ. If they are looking up anything else, they use
google dns servers.
here's the relevant config:
dns-proxy {
interface {
interface facing users;
}
default-domain * {
forwarders {
8.8.8.8;
8.8.4.4;
}
}
default-domain corp.example.com {
forwarders {
corp hq name server1;
corp hq name server 2;
}
}
}
the problem is without the 'default address selection' set the SRX
tries to
use the untrust interface IP as the source IP to query our corp HQ
name
servers, but the traffic doesn't enter the tunnel because it doesn't
match
the vpn policy. And I can't change the policy to allow it because the
untrust interface IP is the endpoint of the tunnel. It looks like the
source zone of the dns query is junos-host- is it possible maybe to
set
up
a junos-host zone to untrust zone NAT when going to corp-hq IP space?
or is there another clever solution?
thanks!
-andy
Re: [j-nsp] Drawbacks when using QFX5100 and EX4300 in mixed VCF mode
+1 regarding input on VCF Does anyone have any practical experience with a VCF either mixed-mode or not? We're evaluating it as a replacement for legacy 6509s. Cisco is pitching a Nexus 6004 + FEX solution. regards, -andy On Tue, Aug 19, 2014 at 8:54 AM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: * Sebastian Wiesinger juniper-...@ml.karotte.org [2014-08-19 17:51]: Hello, Juniper supports mixing QFX5100 and EX4300 in a Virtual Chassis Fabric mixed mode but they talk about some vague performance and/or impact when doing so: Aaand after I sent this, I get the link to a page listing the features for mixed/non-mixed VCF: http://www.juniper.net/techpubs/en_US/junos13.2/topics/reference/general/ex-qfx-series-software-features-overview-vcf.html Still, if someone has practical input on VCF in general or caveats I'd like to hear it. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ 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] SRX Active/Passive cluster with redundant route based IPSec - connectivity to AWS VPC
Hi All, Two related questions. I have a pair of SRX 3400s in an Active/Passive cluster. They rely on an external gateway for internet access (i.e. my ISPs don't terminate on the SRXs). I am setting up redundant tunnels to an AWS VPC. Amazon has an example for J-Series ( http://docs.aws.amazon.com/AmazonVPC/latest/NetworkAdminGuide/Juniper.html), but I don't think it's for a cluster set-up. Here are my questions: 1 - If I want to set up a redundant secure tunnel interface (e.g. st0), should i bind it to an reth interface? 2 - Has anyone connected an Active/Passive SRX cluster to an AWS VPC? Any tips or tricks you care to share? regards, -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Active/Passive cluster with redundant route based IPSec - connectivity to AWS VPC
Hi Morgan, I presume that with regards to the loopback you are referring to the external interface I use as my IPSec peer toward Amazon? what about the internal logical st interface that I need to create in order to route my internal traffic into the tunnel? How do I make that redundant? thanks! -andy On Mon, May 5, 2014 at 3:30 PM, Morgan McLean wrx...@gmail.com wrote: Use your loopback and put that in a reth. Thanks, Morgan On Mon, May 5, 2014 at 3:23 PM, Andy Litzinger andy.litzinger.li...@gmail.com wrote: Hi All, Two related questions. I have a pair of SRX 3400s in an Active/Passive cluster. They rely on an external gateway for internet access (i.e. my ISPs don't terminate on the SRXs). I am setting up redundant tunnels to an AWS VPC. Amazon has an example for J-Series ( http://docs.aws.amazon.com/AmazonVPC/latest/NetworkAdminGuide/Juniper.html ), but I don't think it's for a cluster set-up. Here are my questions: 1 - If I want to set up a redundant secure tunnel interface (e.g. st0), should i bind it to an reth interface? 2 - Has anyone connected an Active/Passive SRX cluster to an AWS VPC? Any tips or tricks you care to share? regards, -andy ___ 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] SA SSL VPN vulnerable to Heartbleed?
I opened a JTAC case for the same issue. JTAC said their security team is
aware of the CVE and they are waiting for fix/recommendation.
-andy
On 4/8/14 2:51 PM, David B Funk dbf...@engineering.uiowa.edu wrote:
We have a SA4500 SSL VPN box with the JTAC recommended 7.4R8.0 release.
Testing by tools such as https://www.ssllabs.com/ssltest/; shows it to
be vulnerable to the Heartbleed attack (http://heartbleed/).
Checking software downloads at juniper.net does not even seem to
have an alert for this problem, let alone a fix.
Does Juniper have a clue about this?
Is anybody else worried?
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
___
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] SA SSL VPN vulnerable to Heartbleed?
Sounds like an advisory is coming today:
The Juniper SIRT is fully aware of the vulnerability and Engineering is
working on fixes for affected releases of Junos OS and IVE OS. Juniper will be
providing an out-of-cycle advisory (JSA) on this issue later today (April 8th,
2014). Junos OS 13.3 and above use OpenSSL 1.0.1 which is affected by this
vulnerability, while earlier versions use OpenSSL 0.9.8 and are unaffected by
this vulnerability. SA 7.4r1 and UAC 4.4r1 are also confirmed as vulnerable,
since they use OpenSSL 1.0.1. PR 981102 has been submitted for Junos to
upgrade OpenSSL to 1.0.1g, and PR 981148 has been submitted for IVE OS to
disable TLS heartbeat.
SSL VPN (IVEOS) 7.3, 7.2, and 7.1 are not vulnerable
On Apr 8, 2014, at 3:41 PM, Andy Litzinger andy.litzin...@theplatform.com
wrote:
I opened a JTAC case for the same issue. JTAC said their security team is
aware of the CVE and they are waiting for fix/recommendation.
-andy
On 4/8/14 2:51 PM, David B Funk dbf...@engineering.uiowa.edu wrote:
We have a SA4500 SSL VPN box with the JTAC recommended 7.4R8.0 release.
Testing by tools such as https://www.ssllabs.com/ssltest/; shows it to
be vulnerable to the Heartbleed attack (http://heartbleed/).
Checking software downloads at juniper.net does not even seem to
have an alert for this problem, let alone a fix.
Does Juniper have a clue about this?
Is anybody else worried?
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
___
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
[j-nsp] Least impactful way to migrate from private ASN to public ASN
We have two MX80 routers that currently each have an eBGP neighbor to the same upstream ISP and are iBGP neighbors. We are using the same internal ASN for both iBGP and eBGP. It's the autonomous-system number defined under routing-options. We're adding a second peer and have recently received our public AS from RIPE. Currently we are only receiving default routes from our upstream ISP. The new peer will only be advertising a small section of their space to us. With respect to configuration changes on the MX80s, what is the least impactful way to move from the private ASN to the public? since we're only receiving default routes is it enough to simply change the ASN on one router at a time while coordinating the change with the ISP at the same time? I presume my iBGP session will break until i replicate the same change on the other side, but will that really impact anything in this case? thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] eBGP neighbor link failure detection
Hi Payam, yes the logs clearly show that the failures start after the link goes down. We have external monitors set up via a 3rd party monitoring ASP that watch our various services. Some, but not all, of them reported connection issues for about 4 minutes. We also run 'rpm' probes from the MX80s toward 4 different destinations. The MX80 that had the peer go down logged all 4 of these probes failing for 2m 48s. The probes are set with a test-interval of 60, probe-count of 10 and a total-loss threshold of 1. Our 2nd MX80 did not have any rpm probes fail. It is an eBGP peer with another provider taking full routes and an iBGP peer with the other MX80. Here is the sequence of events (fictional time starting at 0s) 0m0s - MX80 A logs interface toward neighbor is down - tfeb0 UPDN msg to kernel for ifd:xe-x/x/x, flag:2, speed: 0, duplex:0 0m0s - MX80 A logs BGP neighbor state change - rpd[1344]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer x.x.x.x (External AS Y) changed state from Established to Idle (event Stop) 0m2s - First rpm icmp probe logs failure - rmopd[1348]: PING_PROBE_FAILED: pingCtlOwnerIndex = ICMP-Probe, pingCtlTestName = our-probe-name 0m2s - 3m48s - all icmp probes fail 3m48s - First rpm icmp probe succeeds mopd[1348]: PING_TEST_COMPLETED: pingCtlOwnerIndex = ICMP-Probe, pingCtlTestName = our-probe-name 12m12s - MX80 A logs interface toward neighbor is up - tfeb0 UPDN msg to kernel for ifd:xe-x/x/x, flag:1, speed: 0, duplex:0 12m15s - MX80 A logs BGP neighbor state change to Established - rpd[1344]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer x.x.x.x (External AS Y) changed state from OpenConfirm to Established (event RecvKeepAlive) -andy On Thu, Mar 13, 2014 at 5:17 PM, Payam Chychi pchy...@gmail.com wrote: Are you sure? Ive never seen an update to remove routes take 3min. Andy, are you sure the 3min outage was after the link hard down and not just prior? Guessing this is easy to find due to time stamps. Ive seen this due to line protocol down and everything blackholes until bgp fails but never a 3mim wait for route withdraw (unless this is a peering router with dozens of peers and full routes on each) Hope you fins root cause -- Payam Chychi Network Engineer / Security Specialist On Thursday, March 13, 2014 at 4:50 PM, Andy Litzinger wrote: Hi Chris, yes, i am taking full routes from this neighbor. is there any way to reduce the time it takes to handle the updates? if i wanted to test this behavior in my lab, what would i want to watch? (logs/traceoptions) i don't think I've seen this behavior during scheduled maintenance- for example during times when i've deactivated the neighbor config. Am I correct in thinking this is because in this scenario even though the RE is taking awhile to remove the routes from the FIB the actual next hop router is still available and thus the routes are still valid? -andy On Thu, Mar 13, 2014 at 3:54 PM, Chris Adams c...@cmadams.net wrote: Once upon a time, Andy Litzinger andy.litzinger.li...@gmail.com said: what surprised me is that it looks like routes toward that provider were not immediately removed from my routing table. Instead i see evidence of blackholing for almost 3 minutes. Are you taking full routes from this neighbor? It takes a while for the routing engine to send updates to remove/replace 200k+ prefixes to the forwarding engine. -- Chris Adams c...@cmadams.net ___ 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] eBGP neighbor link failure detection
Hi John, you might be spot on- graceful restart is configured for this peer and it does look like my side is respecting it: show bgp neighbor snip Options: Preference HoldTime AuthKey GracefulRestart LogUpDown PeerAS Refresh I'll let you know what I find out -andy On Thu, Mar 13, 2014 at 7:10 PM, John Neiberger jneiber...@gmail.comwrote: I've only seen something like this once and it was a graceful restart issueerfeature on a Cisco router, so I doubt it's the same problem here. In that situation, the router waited for a graceful restart timer to expire before it would clear out the routes, and it was doing this despite the fact that it had never received a signal that the other side was doing a graceful restart. It seems unlikely that you'd be seeing the same type of problem, but the symptoms sound very similar. John On Thu, Mar 13, 2014 at 3:38 PM, Andy Litzinger andy.litzinger.li...@gmail.com wrote: One of my providers (and eBGP neighbor) recently had a hardware failure which caused the port that connects our two routers to go down. My router did detect the link failure and BGP pretty much immediately transitioned to an Idle state. my side is a Juniper MX80 running 11.4, their side I believe is a Cisco 6509. what surprised me is that it looks like routes toward that provider were not immediately removed from my routing table. Instead i see evidence of blackholing for almost 3 minutes. Is this normal behavior? is the behavior configurable? I thought it might be related to the BGP holdtime, but that appears to be set for 30 seconds. I see that cisco has a feature called 'fast-external-fallover' that bypasses the hold-down timer. Is there an equivalent in JunOS? what is the Juniper best practice to handle link failure between eBGP neighbors? thanks! -andy ___ 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] eBGP neighbor link failure detection
John, do you have any idea how to view the negotiated parameters for Graceful Restart? Or peak into its current state? I tried setting traceoptions: protocols bgp group my-group traceoptions flag graceful-restart detail but that hasn't yielded any log messages. perhaps negotiation only happens at BGP session initiation. is it fair to say that if you are directly connected to your neighbor and that interface goes down that the expected behavior of GR is it should abort and routes from that neighbor should immediately be removed? -andy On Fri, Mar 14, 2014 at 8:52 AM, Andy Litzinger andy.litzinger.li...@gmail.com wrote: Hi John, you might be spot on- graceful restart is configured for this peer and it does look like my side is respecting it: show bgp neighbor snip Options: Preference HoldTime AuthKey GracefulRestart LogUpDown PeerAS Refresh I'll let you know what I find out -andy On Thu, Mar 13, 2014 at 7:10 PM, John Neiberger jneiber...@gmail.comwrote: I've only seen something like this once and it was a graceful restart issueerfeature on a Cisco router, so I doubt it's the same problem here. In that situation, the router waited for a graceful restart timer to expire before it would clear out the routes, and it was doing this despite the fact that it had never received a signal that the other side was doing a graceful restart. It seems unlikely that you'd be seeing the same type of problem, but the symptoms sound very similar. John On Thu, Mar 13, 2014 at 3:38 PM, Andy Litzinger andy.litzinger.li...@gmail.com wrote: One of my providers (and eBGP neighbor) recently had a hardware failure which caused the port that connects our two routers to go down. My router did detect the link failure and BGP pretty much immediately transitioned to an Idle state. my side is a Juniper MX80 running 11.4, their side I believe is a Cisco 6509. what surprised me is that it looks like routes toward that provider were not immediately removed from my routing table. Instead i see evidence of blackholing for almost 3 minutes. Is this normal behavior? is the behavior configurable? I thought it might be related to the BGP holdtime, but that appears to be set for 30 seconds. I see that cisco has a feature called 'fast-external-fallover' that bypasses the hold-down timer. Is there an equivalent in JunOS? what is the Juniper best practice to handle link failure between eBGP neighbors? thanks! -andy ___ 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] eBGP neighbor link failure detection
One of my providers (and eBGP neighbor) recently had a hardware failure which caused the port that connects our two routers to go down. My router did detect the link failure and BGP pretty much immediately transitioned to an Idle state. my side is a Juniper MX80 running 11.4, their side I believe is a Cisco 6509. what surprised me is that it looks like routes toward that provider were not immediately removed from my routing table. Instead i see evidence of blackholing for almost 3 minutes. Is this normal behavior? is the behavior configurable? I thought it might be related to the BGP holdtime, but that appears to be set for 30 seconds. I see that cisco has a feature called 'fast-external-fallover' that bypasses the hold-down timer. Is there an equivalent in JunOS? what is the Juniper best practice to handle link failure between eBGP neighbors? thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] eBGP neighbor link failure detection
Hi Chris, yes, i am taking full routes from this neighbor. is there any way to reduce the time it takes to handle the updates? if i wanted to test this behavior in my lab, what would i want to watch? (logs/traceoptions) i don't think I've seen this behavior during scheduled maintenance- for example during times when i've deactivated the neighbor config. Am I correct in thinking this is because in this scenario even though the RE is taking awhile to remove the routes from the FIB the actual next hop router is still available and thus the routes are still valid? -andy On Thu, Mar 13, 2014 at 3:54 PM, Chris Adams c...@cmadams.net wrote: Once upon a time, Andy Litzinger andy.litzinger.li...@gmail.com said: what surprised me is that it looks like routes toward that provider were not immediately removed from my routing table. Instead i see evidence of blackholing for almost 3 minutes. Are you taking full routes from this neighbor? It takes a while for the routing engine to send updates to remove/replace 200k+ prefixes to the forwarding engine. -- Chris Adams c...@cmadams.net ___ 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] Multicast/Broadcast Packets going to EX CPU
Chris, can you elaborate on why low TTL on multicast frames will cause high CPU? Sebastien, as Chris pointed out anything in the 224.0.0.0/24 will hit the CPU, but so will a few other ranges that fall into the Link-Local block. This is a good guide someone else on the list forwarded me a few months back: http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml#wp1002391 do you have any other multicast sources hitting the 4500? I kind of doubt you've got enough VRRP traffic to peg your CPU. I believe you can put a multicast policier in your lo0 filter, but you need to size it appropriately to allow the multicast required in your network (including things like VRRP). HTH, -andy From: juniper-nsp [juniper-nsp-boun...@puck.nether.net] on behalf of Chris Evans [chrisccnpsp...@gmail.com] Sent: Wednesday, March 05, 2014 6:52 AM To: Juniper NSP Subject: Re: [j-nsp] Multicast/Broadcast Packets going to EX CPU low TTL on the multicast frames will cause this.. Also the multicast destination addresses will do this too if they're in 224.0.0.0/24 On Wed, Mar 5, 2014 at 8:49 AM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: Hello, I'm currently looking at an EX4500 setup that had a few problems related to multicast/broadcast packets going to the CPU (and sometimes preventing required packets like LACP reaching the CPU) of the switch. I assume this was because the queue between PFE and CPU was full (is there a way to check?). I noticed that multicast and broadcast packets in all VLANs are sent to the CPU. My question is why? IGMP snooping and VSTP is not enabled on the switch and apart from that I don't see an apparent reason why it should do this for tagged frames. Example of packets being sent to the CPU includes VRRP packets from attached routers (DMAC 01:00:5e:00:00:12) and BOOTP/DHCP (DMAC ff:ff:ff:ff:ff:ff) packets. Would an lo0 firewall filter help? Is this applied before or after the packets are sent over the PFE-CPU link? Perhaps you could share your ideas on how this could be prevented and what you're doing to protect the CPU on these EX boxes. Regards Seastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ 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] Procedure to add a NPC to SRX HA cluster
Hi Muhammad, yes, JTAC agrees with you :). We installed the NPCs using the KB procedure today and had no issues. thanks! -andy From: Muhammad Atif Jauhar [mailto:atif.jau...@gmail.com] Sent: Saturday, November 16, 2013 10:54 AM To: Andy Litzinger Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Procedure to add a NPC to SRX HA cluster Hi Andy, As per your procedure, Once you boot up node 1 after installing NPC, there will be mismatch in hardware spics of both firewall which will cause cluster issue. Cluster will not comes up if there is mismatch in JUNOS, Hardware even modules are not installed on same slots. Best solution is provided by JTAC. Regards, Muhammad Atif Jauhar On Wed, Nov 13, 2013 at 1:32 AM, Andy Litzinger andy.litzin...@theplatform.commailto:andy.litzin...@theplatform.com wrote: can anyone recommend a procedure to add an NPC card to an SRX HA (active/standby) cluster? In this case it's a pair of SRX3400s, running 12.1X44-D10.4 I've only got two redundancy groups, RG0(control) and RG1(data). Currently the only NPC in each SRX is the integrated NPC-IOC 10GbE card in each chassis Node0 is primary for both RG0 and RG1. I'm not currently running any dynamic routing protocols. There are some Policy based VPNs, ALGs and NATs in place. Can I do something like the following? * power down node 1, install the NPC, boot up and verify status * manually fail RG1 to node1 via request chassis cluster failover * manually fail RG0 to node1 via request chassis cluster failover (is the best way to do this?) * power down node 1, install NPC, boot up and verify status * fail both RG1 and RG0 back to node0 JTAC's first response was to follow this guide: http://kb.juniper.net/InfoCenter/index?page=contentid=KB26674 which seems overly complicated and possibly not applicable. It seems to deal with the case of wanting to move a live SPC from one slot to another. They say it applies to an NPC- but I'm not moving a live NPC, I'm inserting a new one. thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto: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 fab links through EX VC- seeing enumerating MAC addresses
an update- we finally moved our SRX fab links off of the EX switch and the CPU load on the EX did not change. -andy -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Andy Litzinger Sent: Saturday, October 05, 2013 7:51 AM To: Phil Fagan Cc: juniper-nsp Subject: Re: [j-nsp] SRX fab links through EX VC- seeing enumerating MAC addresses I believe it was set vlans vlan name disable-Mac-learning Xe-2 is not the backup RE. 1 3 are the primary and backups respectively. -andy On Oct 4, 2013, at 6:59 PM, Phil Fagan philfa...@gmail.commailto:philfa...@gmail.com wrote: What was the syntax to kill the learning? This is indeed a strange one. I wonder if it would happen on a stand alone switch vs VC. Also is xe-2 your backup for the VC? Wonder if its busy pushing tables to the backup. On Oct 4, 2013 5:50 PM, Andy Litzinger andy.litzin...@theplatform.commailto:andy.litzin...@theplatform.com wrote: While I was logged in planning to configure the mac address aging you suggested I noticed there is another knob to completely disable mac learning on the vlan. Since there are only two ports on this vlan and they're only sending to each other anyway they should really need to learn any macs. so I disabled it and let it run for 1 minute (via commit confirm 1). The entries dropped out of the mac-learning-log, but it didn't have any noticeable impact on my CPU. the mac enumeration still seems like a weird deal though. I'll report back anything JTAC uncovers. -andy From: Phil Fagan [mailto:philfa...@gmail.commailto:philfa...@gmail.com] Sent: Friday, October 04, 2013 2:52 PM To: Andy Litzinger Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX fab links through EX VC- seeing enumerating MAC addresses Very little is said other than indeed using MAC addresses is how the cluster speaks via the FAB http://forums.juniper.net/jnet/attachments/jnet/srx/1659/1/L2HAAppNote v2.pdf As you noted direct connect FAB is ideal; but a very very interesting find. Its possible there is a correct aging for your SRX VLAN that might help the CPU. https://www.juniper.net/techpubs/en_US/junos/topics/reference/configur ation-statement/mac-table-aging-time-bridging.html On Fri, Oct 4, 2013 at 2:45 PM, Andy Litzinger andy.litzin...@theplatform.commailto:andy.litzin...@theplatform.com wrote: Hi, while troubleshooting high CPU on our EX mixed-mode VC (4200 and 4550) our JTAC engineer noticed that one pair of ports is making changes to the MAC learning table at an alarming rate. My SRX3400 fab links are connected to the ports in question (I'm waiting on parts to correct this and directly connect the fab ports). If you watch the mac-learning-log it looks like the SRX is sending packets over the fab link that use a private/fake Ethernet address and are quickly enumerating through a list of Ethernet addresses. Has anyone else ever seen this? is there a way to stop it or minimize its potential effect on the switch cpu? Note that it's not yet proven this is the source of the high cpu. show ethernet-switching mac-learning-log snip Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:32:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a0:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:50:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:61:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:26:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:17:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a1:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:44:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a2:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a3:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:48:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:1b:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:2a:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a4:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a5:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:51:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a6:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:60:00:00
[j-nsp] Procedure to add a NPC to SRX HA cluster
can anyone recommend a procedure to add an NPC card to an SRX HA (active/standby) cluster? In this case it's a pair of SRX3400s, running 12.1X44-D10.4 I've only got two redundancy groups, RG0(control) and RG1(data). Currently the only NPC in each SRX is the integrated NPC-IOC 10GbE card in each chassis Node0 is primary for both RG0 and RG1. I'm not currently running any dynamic routing protocols. There are some Policy based VPNs, ALGs and NATs in place. Can I do something like the following? * power down node 1, install the NPC, boot up and verify status * manually fail RG1 to node1 via request chassis cluster failover * manually fail RG0 to node1 via request chassis cluster failover (is the best way to do this?) * power down node 1, install NPC, boot up and verify status * fail both RG1 and RG0 back to node0 JTAC's first response was to follow this guide: http://kb.juniper.net/InfoCenter/index?page=contentid=KB26674 which seems overly complicated and possibly not applicable. It seems to deal with the case of wanting to move a live SPC from one slot to another. They say it applies to an NPC- but I'm not moving a live NPC, I'm inserting a new one. thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX1400 Forward Proxy
If you want your browser to support a self-signed cert you probably need to import it into your OS's trusted certificate store. In some cases you might be able to import it into your browsers trusted CA store, but I think for a self-signed (vs local CA signed) will have to be imported into your OS's trusted certificate store. hth, -andy -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of EZ Joe Sent: Wednesday, October 16, 2013 1:46 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] SRX1400 Forward Proxy Hi, Have anyone tried using SSL Forward proxy on High end SRX? I've tested using self signed openssl cert, but having problem with the browser reporting certificate not trusted. Is there anyway to workaround this? With Regard EZ Joe - Via Aiped ___ 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 fab links through EX VC- seeing enumerating MAC addresses
I believe it was set vlans vlan name disable-Mac-learning
Xe-2 is not the backup RE. 1 3 are the primary and backups respectively.
-andy
On Oct 4, 2013, at 6:59 PM, Phil Fagan
philfa...@gmail.commailto:philfa...@gmail.com wrote:
What was the syntax to kill the learning? This is indeed a strange one. I
wonder if it would happen on a stand alone switch vs VC. Also is xe-2 your
backup for the VC? Wonder if its busy pushing tables to the backup.
On Oct 4, 2013 5:50 PM, Andy Litzinger
andy.litzin...@theplatform.commailto:andy.litzin...@theplatform.com wrote:
While I was logged in planning to configure the mac address aging you suggested
I noticed there is another knob to completely disable mac learning on the vlan.
Since there are only two ports on this vlan and they’re only sending to each
other anyway they should really need to learn any macs. so I disabled it and
let it run for 1 minute (via commit confirm 1). The entries dropped out of the
mac-learning-log, but it didn’t have any noticeable impact on my CPU.
the mac enumeration still seems like a weird deal though. I’ll report back
anything JTAC uncovers.
-andy
From: Phil Fagan [mailto:philfa...@gmail.commailto:philfa...@gmail.com]
Sent: Friday, October 04, 2013 2:52 PM
To: Andy Litzinger
Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SRX fab links through EX VC- seeing enumerating MAC
addresses
Very little is said other than indeed using MAC addresses is how the cluster
speaks via the FAB
http://forums.juniper.net/jnet/attachments/jnet/srx/1659/1/L2HAAppNotev2.pdf
As you noted direct connect FAB is ideal; but a very very interesting find.
Its possible there is a correct aging for your SRX VLAN that might help the CPU.
https://www.juniper.net/techpubs/en_US/junos/topics/reference/configuration-statement/mac-table-aging-time-bridging.html
On Fri, Oct 4, 2013 at 2:45 PM, Andy Litzinger
andy.litzin...@theplatform.commailto:andy.litzin...@theplatform.com wrote:
Hi,
while troubleshooting high CPU on our EX mixed-mode VC (4200 and 4550) our JTAC
engineer noticed that one pair of ports is making changes to the MAC learning
table at an alarming rate. My SRX3400 fab links are connected to the ports in
question (I'm waiting on parts to correct this and directly connect the fab
ports). If you watch the mac-learning-log it looks like the SRX is sending
packets over the fab link that use a private/fake Ethernet address and are
quickly enumerating through a list of Ethernet addresses.
Has anyone else ever seen this? is there a way to stop it or minimize its
potential effect on the switch cpu? Note that it's not yet proven this is the
source of the high cpu.
show ethernet-switching mac-learning-log
snip
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:32:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a0:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:50:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:61:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:26:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:17:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a1:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:44:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a2:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a3:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:48:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:1b:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:2a:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a4:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a5:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:51:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a6:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:60:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:33:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a7:00:00 was
learned on xe-2/0/28.0
the EX port config:
show configuration interfaces xe-0/0/28
Oct 04 13:00:13
description srx01-xe-1/0/1;
mtu 9216;
unit 0 {
family ethernet-switching {
vlan {
members 500;
}
}
}
show configuration
[j-nsp] SRX fab links through EX VC- seeing enumerating MAC addresses
Hi,
while troubleshooting high CPU on our EX mixed-mode VC (4200 and 4550) our JTAC
engineer noticed that one pair of ports is making changes to the MAC learning
table at an alarming rate. My SRX3400 fab links are connected to the ports in
question (I'm waiting on parts to correct this and directly connect the fab
ports). If you watch the mac-learning-log it looks like the SRX is sending
packets over the fab link that use a private/fake Ethernet address and are
quickly enumerating through a list of Ethernet addresses.
Has anyone else ever seen this? is there a way to stop it or minimize its
potential effect on the switch cpu? Note that it's not yet proven this is the
source of the high cpu.
show ethernet-switching mac-learning-log
snip
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:32:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a0:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:50:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:61:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:26:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:17:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a1:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:44:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a2:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a3:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:48:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:1b:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:2a:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a4:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a5:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:51:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a6:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:60:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:33:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a7:00:00 was
learned on xe-2/0/28.0
the EX port config:
show configuration interfaces xe-0/0/28
Oct 04 13:00:13
description srx01-xe-1/0/1;
mtu 9216;
unit 0 {
family ethernet-switching {
vlan {
members 500;
}
}
}
show configuration interfaces xe-2/0/28
Oct 04 13:32:52
description srx02-xe-1/0/1;
mtu 9216;
unit 0 {
family ethernet-switching {
vlan {
members 500;
}
}
}
SRX:
srx01 show configuration interfaces fab0
fabric-options {
member-interfaces {
xe-1/0/1;
}
}
srx01 show configuration interfaces fab1
fabric-options {
member-interfaces {
xe-9/0/1;
}
}
srx01 show configuration interfaces xe-1/0/1
srx01 show configuration interfaces xe-9/0/1
srx01
thanks!
-andy
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX fab links through EX VC- seeing enumerating MAC addresses
While I was logged in planning to configure the mac address aging you suggested
I noticed there is another knob to completely disable mac learning on the vlan.
Since there are only two ports on this vlan and they’re only sending to each
other anyway they should really need to learn any macs. so I disabled it and
let it run for 1 minute (via commit confirm 1). The entries dropped out of the
mac-learning-log, but it didn’t have any noticeable impact on my CPU.
the mac enumeration still seems like a weird deal though. I’ll report back
anything JTAC uncovers.
-andy
From: Phil Fagan [mailto:philfa...@gmail.com]
Sent: Friday, October 04, 2013 2:52 PM
To: Andy Litzinger
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SRX fab links through EX VC- seeing enumerating MAC
addresses
Very little is said other than indeed using MAC addresses is how the cluster
speaks via the FAB
http://forums.juniper.net/jnet/attachments/jnet/srx/1659/1/L2HAAppNotev2.pdf
As you noted direct connect FAB is ideal; but a very very interesting find.
Its possible there is a correct aging for your SRX VLAN that might help the CPU.
https://www.juniper.net/techpubs/en_US/junos/topics/reference/configuration-statement/mac-table-aging-time-bridging.html
On Fri, Oct 4, 2013 at 2:45 PM, Andy Litzinger
andy.litzin...@theplatform.commailto:andy.litzin...@theplatform.com wrote:
Hi,
while troubleshooting high CPU on our EX mixed-mode VC (4200 and 4550) our JTAC
engineer noticed that one pair of ports is making changes to the MAC learning
table at an alarming rate. My SRX3400 fab links are connected to the ports in
question (I'm waiting on parts to correct this and directly connect the fab
ports). If you watch the mac-learning-log it looks like the SRX is sending
packets over the fab link that use a private/fake Ethernet address and are
quickly enumerating through a list of Ethernet addresses.
Has anyone else ever seen this? is there a way to stop it or minimize its
potential effect on the switch cpu? Note that it's not yet proven this is the
source of the high cpu.
show ethernet-switching mac-learning-log
snip
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:32:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a0:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:50:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:61:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:26:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:17:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a1:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:44:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a2:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a3:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:48:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:1b:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:2a:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a4:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a5:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:51:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a6:00:00 was
learned on xe-2/0/28.0
Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:60:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:33:00:00 was
deleted on xe-0/0/28.0
Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a7:00:00 was
learned on xe-2/0/28.0
the EX port config:
show configuration interfaces xe-0/0/28
Oct 04 13:00:13
description srx01-xe-1/0/1;
mtu 9216;
unit 0 {
family ethernet-switching {
vlan {
members 500;
}
}
}
show configuration interfaces xe-2/0/28
Oct 04 13:32:52
description srx02-xe-1/0/1;
mtu 9216;
unit 0 {
family ethernet-switching {
vlan {
members 500;
}
}
}
SRX:
srx01 show configuration interfaces fab0
fabric-options {
member-interfaces {
xe-1/0/1;
}
}
srx01 show configuration interfaces fab1
fabric-options {
member-interfaces {
xe-9/0/1;
}
}
srx01 show configuration interfaces xe-1/0/1
srx01 show configuration interfaces xe-9/0/1
srx01
thanks!
-andy
___
juniper-nsp mailing list
juniper-nsp@puck.nether.netmailto:juniper-nsp
[j-nsp] expected multicast forwarding behavior with igmp-snooping and local igmp querier
maybe this will simply turn out to be a gap in my understanding about multicast
addressing, but my EX4550/4200 VC is not pruning multicast how I would expect.
I have vlan defined with an RVI. I have enabled igmp for that vlan interface.
I have two hosts that are members of the same vlan (server A and server B, vlan
123). igmp-snooping is on for all vlans (factory default setting).
I am using iperf to send/receive test multicast streams from server A to server
B.
With igmp-snooping and igmp running on the vlan, If I send a stream via iperf
from server A, I do not expect that stream to show up on server B until I start
the iperf server at the same multicast address. I expect the switch to not
flood the traffic to all ports in the vlan (including serverB ) but instead
wait until a server explicitly joins the group.
This does not appear to always be true. I obviously haven't tested every
multicast address, but it seems that pretty much all multicast traffic directed
to 224.0.0.0-239.0.0.255 will cause the switch to flood traffic to all ports in
the vlan.
But addresses from 239.0.1.0 and up seem to work as I expect. If server A
sends to 239.0.1.1 and I listen for traffic to that address on server B, I
don't see anything. It seems the switch is pruning as I would expect. As soon
as I start the multicast iperf listener on server B for 239.0.1.1 then my
tcpdump immediately lights up with the multicast traffic- again as I would
expect. In fact the opposite behavior seems to occur- with the 239.0.1.1
address, if I don't have igmp configured on the vlan at all (delete protocols
igmp interface vlan.123) the switch does NOT flood multicast traffic for that
address. I see nothing arrive on server B. this is also unexpected.
can anyone set me straight?
also- what I'm trying to do is relatively simple but maybe I'm going about it
the wrong way. I have groups of servers in the vlan that use multicast packets
as a periodic heartbeat to keep track of each other. I'd like to make sure
the multicast heartbeat only goes to other servers that subscribe to the same
multicast address- not send it to every server in the vlan. does my config
seem like a valid way to do this? I don't need to route the multicast across
subnets.
thanks!
-andy
here are the relevant config snippets and the iperf and tcpdump commands I'm
using:
# show vlans 123
vlan-id 123;
l3-interface vlan.123;
# show interfaces vlan.123
family inet {
address x.x.x.x/24;
}
# show protocols
igmp {
interface vlan.123;
}
igmp-snooping {
vlan all;
}
iperf client (sender): iperf -c 239.0.1.1 -u --ttl 2 -t 30 -i 5
iperf server (receiver): iperf -s -u -B 239.10.1.1 -i 5
tcpdump example: tcpdump -nn host 239.0.1.1
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] trouble setting up link agg between clustered SRX 550 and Cisco 6509
I've had some progress while working with JTAC-thought I'd share.
JTAC pointed out that one of the interfaces I was trying to LAG was not even
coming online. The Cisco side seemed to think it auto-negotiated happily to
1000/Full (but still added it to an independent port-channel); the Juniper
side was marking it down with auto-negotiated speed/duplex at 10/Half.
Obviously we suspected a cabling issue. Rather than drive to the datacenter (a
good engineer never leaves their desk, right?) I decided to try and replicate
the config on the other node in the cluster. so I removed the broken interface
from LAG1 on the cisco end and made node0 the primary node for RG1. I then
configured the LAG on node1 and lo and behold, it came online immediately. so
I failed the RG1 back to node1 and traffic flowed with no issues. node0's
issue is almost certainly cable related, right?
well...
So I decided to play around with LAG1 on node0 again for a bit to see if I
could get it to work. No dice. While messing with the config I left both
ports out of the LAG on the cisco side and forgot to put the working link back
into the LAG.
I decided to press my luck with my new discovery and configure the 2nd LAG
group I needed online. As before I wanted to first set the LAG up on the
standby node (node0 at this point) and make sure LACP was happy before putting
traffic on it. The 2nd LAG on node0 came up with both interfaces with no
issues. I failed RG1 back to node 0, and because I forgot to put my port back
into LAG1 on the cisco side I started blackholing traffic. No problem- I
failed the RG back to node1 and then went to add the previously working port
back to LAG1 on the cisco side.
At this point the interface refused to come up on the SRX side. ge-0/0/4,
which had been working previously, suddenly was acting just like ge-0/0/6. Now
the 'bad-cable' idea was kind of out the window. I spent another hour on the
phone with JTAC. They wanted me to go down and swap in new cables which I said
I could do tomorrow.
In the meantime I made a discovery- If I removed the 'redundant-parent reth0'
from both ge-0/0/4 and ge-0/0/6, and commited, the interfaces both immediately
came up though not part of the LAG of course. Then if I re-added them to reth0
and re-commited the config- both links stayed up and immediately formed a
proper LACP LAG with the 6509. WTH?!!
so I failed RG1 over to node0- things ran smoothly.
Now I only had one more LAG to configure, LAG2 on node1. I added the second
interface on both sides of the config and had the same issue- the 6509 thought
the new link was a-ok and 1000/Full, but added it as an independent member of
the LAG. The SRX marked the link down with 10/Half. Once again I removed the
'redundant-parent reth1' statement from both interfaces and commited. Once
again both interfaces came right up (or stayed up in the case of the already
working interface). Next I re-added the statements and re-commited and Voila,
a working LAG...
I'll be working more with JTAC tomorrow. Although things are working I worry
that they are in a fragile state and any failure of a LAG member may cause an
LACP disagreement between the 6509 and the SRX or force me to remember the
weird workaround to get things back online. Also, although I don't know how
reproducible this is for others, it seems like I may have hit a bug somewhere.
-andy
-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
Of Andy Litzinger
Sent: Thursday, August 15, 2013 3:55 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] trouble setting up link agg between clustered SRX 550 and
Cisco 6509
Has anyone had any difficulty creating a port channel between an SRX cluster
(in this case, SRX 550s) and Cisco switches (in this case 6509s, non-VSS)?
When I tried to bring up a second link in the link agg group the cisco side
put it
in state I which means: standalone. It also logged this message:
%EC-SP-5-CANNOT_BUNDLE_LACP: Gi8/2 is not compatible with aggregators
in channel 10 and cannot attach to them (flow control send of Gi8/2 is on,
Gi8/1 is off)
I did some googling and found a couple articles that seemed to say that the
SRX doesn't support flow-control so I tried turning it off on the cisco side.:
interface 8/1 flowcontrol send off
interface 8/2 flowcontrol send off
interface po10 flowconftorl send off
This didn't help and when I shut/no shut the port channel on the cisco side
the whole thing went offline and wouldn't come back until I rebuilt it.
any ideas?
SRX-A connects to 6509-A with 2 physical links bundled into reth0 SRX-B
connects to 6509-B with 2 physical links bundled into reth0
SRX side config:
show configuration interfaces ge-0/0/4
gigether-options {
redundant-parent reth0;
}
show configuration interfaces ge-0/0/6
gigether-options {
redundant-parent reth0;
}
show configuration
Re: [j-nsp] trouble setting up link agg between clustered SRX 550 and Cisco 6509
Hi Per,
thanks for your suggestion. I've set it up this way because I'm following
this kb: https://kb.juniper.net/InfoCenter/index?page=contentid=KB22474
it's not exactly apples to apples since I'm not connecting to an EX and I'm
connecting to two switches instead of one, but I don't think those details
matter in this case.
Also, several people have pointed out that in the config I posted I had a
difference with the channel mode (active vs passive) on the cisco side between
the two ports I'm trying to aggregate. I apologize- that is just the state I
left it in during troubleshooting. you'll note that the second interface, 8/2,
is also actually shutdown in the config I posted. I have tried setting both to
active and both to passive with no luck.
-andy
-Original Message-
From: Per Westerlund [mailto:p...@westerlund.se]
Sent: Friday, August 16, 2013 12:54 AM
To: Andy Litzinger
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] trouble setting up link agg between clustered SRX 550
and Cisco 6509
The components of the SRX RETH-interfaces are not all active at the same
time, this is a fail-over construct. One active link at the time.
You should be looking at the AE-interfaces instead, they are proper LACP
aggregators.
/Per
16 aug 2013 kl. 00:55 skrev Andy Litzinger
andy.litzin...@theplatform.com:
Has anyone had any difficulty creating a port channel between an SRX
cluster (in this case, SRX 550s) and Cisco switches (in this case 6509s, non-
VSS)?
When I tried to bring up a second link in the link agg group the cisco side
put
it in state I which means: standalone. It also logged this message:
%EC-SP-5-CANNOT_BUNDLE_LACP: Gi8/2 is not compatible with
aggregators
in channel 10 and cannot attach to them (flow control send of Gi8/2 is
on, Gi8/1 is off)
I did some googling and found a couple articles that seemed to say that the
SRX doesn't support flow-control so I tried turning it off on the cisco side.:
interface 8/1 flowcontrol send off
interface 8/2 flowcontrol send off
interface po10 flowconftorl send off
This didn't help and when I shut/no shut the port channel on the cisco side
the whole thing went offline and wouldn't come back until I rebuilt it.
any ideas?
SRX-A connects to 6509-A with 2 physical links bundled into reth0
SRX-B connects to 6509-B with 2 physical links bundled into reth0
SRX side config:
show configuration interfaces ge-0/0/4
gigether-options {
redundant-parent reth0;
}
show configuration interfaces ge-0/0/6
gigether-options {
redundant-parent reth0;
}
show configuration interfaces ge-9/0/4
gigether-options {
redundant-parent reth0;
}
show configuration interfaces ge-9/0/6
gigether-options {
redundant-parent reth0;
}
show configuration interfaces reth0
vlan-tagging;
redundant-ether-options {
redundancy-group 1;
lacp {
active;
periodic fast;
}
}
unit x {
vlan-id x;
family inet {
address x.x.x.x/zz;
}
}
unit y {
vlan-id y;
family inet {
address x.x.x.x/zz;
}
}
cisco side on 6509-A:
interface GigabitEthernet8/1
description srx01-g0/4
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan x,y
switchport mode trunk
switchport nonegotiate
spanning-tree portfast edge trunk
channel-group 10 mode active
end
interface GigabitEthernet8/2
description srx01-g0/6
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan x,y
switchport mode trunk
switchport nonegotiate
shutdown
spanning-tree portfast edge trunk
channel-group 10 mode passive
end
interface Port-channel10
description srx01-internal
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan x,y
switchport mode trunk
switchport nonegotiate
spanning-tree portfast edge trunk
end
the 6509-B config is identical
thanks!
-andy
___
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] trouble setting up link agg between clustered SRX 550 and Cisco 6509
12.1R1.9
I'll check out the link, thanks!
here's a pretty sparse (only shows the SRX side) config example from the
documenation that implies it is possible in 12.1...
https://www.juniper.net/techpubs/en_US/junos12.1/topics/example/chassis-cluster-redundant-ethernet-interface-link-aggregation-group-configuring-cli.html
-andy
-Original Message-
From: Per Westerlund [mailto:p...@westerlund.se]
Sent: Friday, August 16, 2013 3:07 PM
To: Andy Litzinger
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] trouble setting up link agg between clustered SRX 550
and Cisco 6509
What versions are you running?
Apparently L3 support for this type of config was available before the L2
version was ready.
Being lazy, and not having access to equipment where I can set this up, I will
start with a pointer to someone who did a similar thing a while ago:
http://cooperlees.com/blog/?p=401
/Per
16 aug 2013 kl. 17:37 skrev Andy Litzinger
andy.litzin...@theplatform.com:
Hi Per,
thanks for your suggestion. I've set it up this way because I'm
following this kb:
https://kb.juniper.net/InfoCenter/index?page=contentid=KB22474
it's not exactly apples to apples since I'm not connecting to an EX and I'm
connecting to two switches instead of one, but I don't think those details
matter in this case.
Also, several people have pointed out that in the config I posted I had a
difference with the channel mode (active vs passive) on the cisco side
between the two ports I'm trying to aggregate. I apologize- that is just the
state I left it in during troubleshooting. you'll note that the second
interface,
8/2, is also actually shutdown in the config I posted. I have tried setting
both
to active and both to passive with no luck.
-andy
-Original Message-
From: Per Westerlund [mailto:p...@westerlund.se]
Sent: Friday, August 16, 2013 12:54 AM
To: Andy Litzinger
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] trouble setting up link agg between clustered
SRX 550 and Cisco 6509
The components of the SRX RETH-interfaces are not all active at the
same time, this is a fail-over construct. One active link at the time.
You should be looking at the AE-interfaces instead, they are proper
LACP aggregators.
/Per
16 aug 2013 kl. 00:55 skrev Andy Litzinger
andy.litzin...@theplatform.com:
Has anyone had any difficulty creating a port channel between an SRX
cluster (in this case, SRX 550s) and Cisco switches (in this case
6509s, non- VSS)?
When I tried to bring up a second link in the link agg group the
cisco side put
it in state I which means: standalone. It also logged this message:
%EC-SP-5-CANNOT_BUNDLE_LACP: Gi8/2 is not compatible with
aggregators
in channel 10 and cannot attach to them (flow control send of Gi8/2
is on, Gi8/1 is off)
I did some googling and found a couple articles that seemed to say
that the
SRX doesn't support flow-control so I tried turning it off on the cisco
side.:
interface 8/1 flowcontrol send off
interface 8/2 flowcontrol send off
interface po10 flowconftorl send off
This didn't help and when I shut/no shut the port channel on the
cisco side
the whole thing went offline and wouldn't come back until I rebuilt it.
any ideas?
SRX-A connects to 6509-A with 2 physical links bundled into reth0
SRX-B connects to 6509-B with 2 physical links bundled into reth0
SRX side config:
show configuration interfaces ge-0/0/4
gigether-options {
redundant-parent reth0;
}
show configuration interfaces ge-0/0/6
gigether-options {
redundant-parent reth0;
}
show configuration interfaces ge-9/0/4
gigether-options {
redundant-parent reth0;
}
show configuration interfaces ge-9/0/6
gigether-options {
redundant-parent reth0;
}
show configuration interfaces reth0
vlan-tagging;
redundant-ether-options {
redundancy-group 1;
lacp {
active;
periodic fast;
}
}
unit x {
vlan-id x;
family inet {
address x.x.x.x/zz;
}
}
unit y {
vlan-id y;
family inet {
address x.x.x.x/zz;
}
}
cisco side on 6509-A:
interface GigabitEthernet8/1
description srx01-g0/4
switchport
switchport trunk encapsulation dot1q switchport trunk allowed vlan
x,y switchport mode trunk switchport nonegotiate spanning-tree
portfast edge trunk channel-group 10 mode active end
interface GigabitEthernet8/2
description srx01-g0/6
switchport
switchport trunk encapsulation dot1q switchport trunk allowed vlan
x,y switchport mode trunk switchport nonegotiate shutdown
spanning-tree portfast edge trunk channel-group 10 mode passive end
interface Port-channel10
description srx01-internal
switchport
switchport trunk encapsulation dot1q switchport trunk allowed vlan
x,y switchport mode trunk switchport nonegotiate spanning-tree
portfast edge trunk end
the 6509
[j-nsp] trouble setting up link agg between clustered SRX 550 and Cisco 6509
Has anyone had any difficulty creating a port channel between an SRX cluster
(in this case, SRX 550s) and Cisco switches (in this case 6509s, non-VSS)?
When I tried to bring up a second link in the link agg group the cisco side put
it in state I which means: standalone. It also logged this message:
%EC-SP-5-CANNOT_BUNDLE_LACP: Gi8/2 is not compatible with aggregators in
channel 10 and cannot attach to them (flow control send of Gi8/2 is on, Gi8/1
is off)
I did some googling and found a couple articles that seemed to say that the SRX
doesn't support flow-control so I tried turning it off on the cisco side.:
interface 8/1 flowcontrol send off
interface 8/2 flowcontrol send off
interface po10 flowconftorl send off
This didn't help and when I shut/no shut the port channel on the cisco side the
whole thing went offline and wouldn't come back until I rebuilt it.
any ideas?
SRX-A connects to 6509-A with 2 physical links bundled into reth0
SRX-B connects to 6509-B with 2 physical links bundled into reth0
SRX side config:
show configuration interfaces ge-0/0/4
gigether-options {
redundant-parent reth0;
}
show configuration interfaces ge-0/0/6
gigether-options {
redundant-parent reth0;
}
show configuration interfaces ge-9/0/4
gigether-options {
redundant-parent reth0;
}
show configuration interfaces ge-9/0/6
gigether-options {
redundant-parent reth0;
}
show configuration interfaces reth0
vlan-tagging;
redundant-ether-options {
redundancy-group 1;
lacp {
active;
periodic fast;
}
}
unit x {
vlan-id x;
family inet {
address x.x.x.x/zz;
}
}
unit y {
vlan-id y;
family inet {
address x.x.x.x/zz;
}
}
cisco side on 6509-A:
interface GigabitEthernet8/1
description srx01-g0/4
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan x,y
switchport mode trunk
switchport nonegotiate
spanning-tree portfast edge trunk
channel-group 10 mode active
end
interface GigabitEthernet8/2
description srx01-g0/6
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan x,y
switchport mode trunk
switchport nonegotiate
shutdown
spanning-tree portfast edge trunk
channel-group 10 mode passive
end
interface Port-channel10
description srx01-internal
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan x,y
switchport mode trunk
switchport nonegotiate
spanning-tree portfast edge trunk
end
the 6509-B config is identical
thanks!
-andy
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Firewall filter -EX4500
I think your source ip range netmask should be /0, not /32. I.e: 0.0.0.0/0
On Jul 9, 2013, at 6:19 AM, Brijesh Patel brju.pa...@gmail.com wrote:
Hi All,
EX4500 firewall filter configuration :
Connectivity : F5 Load balancer - Ex4500 -- Internet
I want to configure ex firewall filter configuration , requirement as below
:
1. Allow from any source/internet to specific *destination
address(F5 load balancer) for any* port for the all network address range
(i.e. 192.168.246.1/24). Host are specified in *F5Traffic-IP prefi list*
My configuration as below :
test@lab-EX4500-01# run show configuration firewall family inet filter
incoming_traffic term LB-Traffic
from {
source-address {
0.0.0.0/32;
}
destination-prefix-list {
F5Traffic-IP;
}
}
then accept;
test@lab-EX4500-01# run show configuration policy-options prefix-list *
F5Traffic-IP*
192.168.246.8/32;
192.168.246.9/32;
192.168.246.225/32;
test@lab-EX4500-01 show configuration interfaces vlan.500
family inet {
filter {
input incoming_traffic;
}
address 192.168.246.1/24;
}
Does my configuration will work OR do I need to specify more in destination
port ? Pls suggest.
Many Thanks ,
Brijesh Patel
___
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] Share static routes between routing-instances on EX series
Thanks all for the tips on and off list. I found this KB
http://kb.juniper.net/InfoCenter/index?page=contentid=KB23027 which states
that it's not possible to leak local direct routes between routing-instances.
Apparently it's a limitation of the EX and even the most recent release notes
still list it as a limitation.
As stated in the KB article the workarounds are FBF and physically connecting
the routing-instances. The second method isn't really explained in the KB- I'm
not sure I follow how to do that or the related capacity and redundancy
implications. Has anyone done it?
-andy
-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
Of Andy Litzinger
Sent: Tuesday, June 18, 2013 4:29 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Share static routes between routing-instances on EX series
I have a network that contains two distinct groups of servers.
Group1 with subnets A,B
Group2 with subnets C,D
Both groups use RVIs on a core VC (mix of EX4550s and 4200s) as their default
route. There are two different paths out of the network. I'd like Group1 to
take path1 and Group2 to take path2. Subnets A,B,C and D should be able to
communicate directly, preferably within the VC (not out to another device
and back).
I can create a routing-instance for each group (or 1 and use the global table
for the other). Adding the RVIs and maintaining a separate default route out
for each routing-instance is no problem. The trouble is trying to allow the
subnets to communicate to each other.
I've tried adding a static route under the routing-instance for Group 1 to a
subnet outside the routing-instance, e.g. a route to subnet C inside routing-
instance for Group1, but the route never shows up in the routing table,
presumably because there isn't a live interface in routing-instance C with a
connection to subnet C. and it doesn't look like there's an option to make
the next-hop an interface instead of an IP.
group1-vr {
instance-type virtual-router;
interface vlan.A;
routing-options {
static {
route C.0/23 next-hop C.1;
}
}
}
root@ex# run show route
snip
group1-vr.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
A.0/23 *[Direct/0] 1d 00:52:00
via vlan.A
A.1/32 *[Local/0] 1d 00:52:00
Local via vlan.A
I will try rib groups next, but I think I read somewhere that EX switches
don't
support importing static routes via rib groups.
I suppose this could also be solved by Filter Based Forwarding, but I'd like
to
avoid that if possible; it just doesn't seem as clean.
thanks in advance!
-andy
___
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] Share static routes between routing-instances on EX series
I have a network that contains two distinct groups of servers.
Group1 with subnets A,B
Group2 with subnets C,D
Both groups use RVIs on a core VC (mix of EX4550s and 4200s) as their default
route. There are two different paths out of the network. I'd like Group1 to
take path1 and Group2 to take path2. Subnets A,B,C and D should be able to
communicate directly, preferably within the VC (not out to another device and
back).
I can create a routing-instance for each group (or 1 and use the global table
for the other). Adding the RVIs and maintaining a separate default route out
for each routing-instance is no problem. The trouble is trying to allow the
subnets to communicate to each other.
I've tried adding a static route under the routing-instance for Group 1 to a
subnet outside the routing-instance, e.g. a route to subnet C inside
routing-instance for Group1, but the route never shows up in the routing table,
presumably because there isn't a live interface in routing-instance C with a
connection to subnet C. and it doesn't look like there's an option to make the
next-hop an interface instead of an IP.
group1-vr {
instance-type virtual-router;
interface vlan.A;
routing-options {
static {
route C.0/23 next-hop C.1;
}
}
}
root@ex# run show route
snip
group1-vr.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
A.0/23 *[Direct/0] 1d 00:52:00
via vlan.A
A.1/32 *[Local/0] 1d 00:52:00
Local via vlan.A
I will try rib groups next, but I think I read somewhere that EX switches don't
support importing static routes via rib groups.
I suppose this could also be solved by Filter Based Forwarding, but I'd like to
avoid that if possible; it just doesn't seem as clean.
thanks in advance!
-andy
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] experience using 10G DAC (twinax) cables between EX and multi-vendor
Has anyone used a 10G DAC/Twinax cable between an EX4550 and other vendor gear? Did you use Juniper DAC cables or the other vendor cables? In particular I'm planning on linking a Cisco UCS Fabric Interconnect and also an F5 BigIP 4200v to a VC of EX4550s. would you recommend it or should I fork over the money to use optics? thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] QFX vs EX4550 as collapsed core
Hi, we're deploying to a new environment where there will be about 500 virtual servers hosted completely on Cisco UCS. The Core would mostly be hosting uplinks to the UCS Fabric Interconnects (End Host Mode), inter-vlan routing and links to service appliances (FW/LB) and the Internet edge routers. Nearly all of our traffic is North/South from server to LB to internet or server to LB to another server. The core would mostly be routing a few (dozens at most) routes so RIB/FIB size shouldn't be a great concern. Most links will be 10G, but there are a handful of 1G management links. We're considering either the QFX3500 ( x2) or the EX4450 (x2 as a VC) to fill this role (or potentially Cisco Nexus 6001) * are there any L3 benefits of one over the other? I haven't found clear numbers in the datasheets * Has anyone actually used MC-LAG on the QFX3500? Is it working well? any caveats? we've also considered collapsing the edge too, but the cost of say an MX-480 with similar port count is about twice that of an MX-80 + QFX/EX thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX upgrade procedure -ready for enterprise?
We're evaluating SRX clusters as replacements for our aging ASAs FO pairs in various places in our network including the Datacenter Edge. I was reading the upgrade procedure KB: http://kb.juniper.net/InfoCenter/index?page=contentid=KB17947 and started to have some heart palpitations. It seems a complicated procedure fraught with peril. Anyone out there have any thoughts (positive/negative) on their experience on upgrading an SRX cluster with minimal downtime? thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX upgrade procedure -ready for enterprise?
what pieces of the KB do you think contribute to the possibility of major outages? Not having tested anything it already makes me nervous that failover is initiated solely by shutting down the interfaces on the active node... -Original Message- From: Tim Eberhard [mailto:xmi...@gmail.com] Sent: Friday, March 08, 2013 10:11 AM To: Andy Litzinger Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX upgrade procedure -ready for enterprise? I would never, ever follow that KB. It's just asking for a major outage.. With that said, you have two options. 1) ISSU and 2) Reboot both close to the same time and take the hit. Depending on your hardware it might be 4 minutes, it might be 8-10 minutes. If option one is the path you choose to go keep in mind the limitations and I would suggest you test it in a lab well before you ever do it in production. ISSU on the SRX is still *very* new. Here is a list of limitations: http://kb.juniper.net/InfoCenter/index?page=contentid=KB17946actp=R SS I've seen ISSU fail more than a couple of times when it was supposed to be fully supported. This caused us to take a hit, then have to reboot both devices anyways. So we ended up expecting a hitless upgrade and got 10 minutes of downtime anyways. If you're up for running bleeding edge code then maybe ISSU will work properly, but if availability is that critical you should have a lab to test this in. Good luck, -Tim Eberhard On Fri, Mar 8, 2013 at 9:50 AM, Andy Litzinger andy.litzin...@theplatform.com wrote: We're evaluating SRX clusters as replacements for our aging ASAs FO pairs in various places in our network including the Datacenter Edge. I was reading the upgrade procedure KB: http://kb.juniper.net/InfoCenter/index?page=contentid=KB17947 and started to have some heart palpitations. It seems a complicated procedure fraught with peril. Anyone out there have any thoughts (positive/negative) on their experience on upgrading an SRX cluster with minimal downtime? thanks! -andy ___ 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 upgrade procedure -ready for enterprise?
ICU sounds interesting. Any idea why it's not supported on the 550? or is that just documentation lag? -Original Message- From: Clay Haynes [mailto:chay...@centracomm.net] Sent: Friday, March 08, 2013 3:08 PM To: Andy Litzinger; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX upgrade procedure -ready for enterprise? I've had really good luck with the ICU Upgrade for branch series. You upload the software package to the active SRX, run the commands, and it handles copying the package to the backup unit and all reboots. There is still a drop in traffic for up to 30 seconds, but for the most part it's much safer than upgrading/rebooting both units simultaneously and praying they come up properly. Again, ICU is supported on branch-series only, and you have run 11.2r2 or later for it to be available. http://www.juniper.net/techpubs/en_US/junos12.1/topics/task/operationa l/cha ssis-cluster-upgrading-and-aborting-backup-and-primary-device-with- icu.html I haven't had great luck on ISSU, but then again I don't have many datacenter-series boxes to play with (300+ SRX650 and below, about 10 SRX1400 and above). I would follow this URL, and if you're running any of these services in the respective code do not proceed with the ISSU: http://kb.juniper.net/InfoCenter/index?page=contentid=KB17946actp=R SS - Clay On 3/8/13 12:50 PM, Andy Litzinger andy.litzin...@theplatform.com wrote: We're evaluating SRX clusters as replacements for our aging ASAs FO pairs in various places in our network including the Datacenter Edge. I was reading the upgrade procedure KB: http://kb.juniper.net/InfoCenter/index?page=contentid=KB17947 and started to have some heart palpitations. It seems a complicated procedure fraught with peril. Anyone out there have any thoughts (positive/negative) on their experience on upgrading an SRX cluster with minimal downtime? thanks! -andy ___ 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] SRX AV cloud vs on-device
Hi all, we're looking at an SRX 550 and have been posed with the choice between using the cloud based anti-virus or the on-device. Are there any compelling reasons to pick one over the other? thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
