Re: [j-nsp] Juniper Case Management down

[Aaron Dewell]

There should have been a banner up for the last few weeks detailing changes 
that were going to happen May 2 to My Juniper. There may have also been an 
email but I don't recall that myself.
http://casemanager.juniper.net is the place to go for your case management 
needs now.
On May 2 2020, at 11:46 am, Clinton Work  wrote:
> Was there any notification about the Juniper case manager going down for 
> scheduled maintenance? The site has been down since last night and we had to 
> get temp case # created via the phone.
>
> https://my.juniper.net/#dashboard/overview
> --
> Clinton Work
> ___
> 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] ftp.juniper.net

[Aaron Dewell]

Definitely.  You can file a report with the “feedback” button on that page and 
it will get updated.

> On Dec 19, 2018, at 10:16 AM, Niall Donaghy  wrote:
> 
> Thanks Saku and Aaron.
> 
> My point is KB15585 should be retired if FTP is no longer supported. =)
> 
> -Original Message-
> From: Aaron Gould [mailto:aar...@gvtc.com] 
> Sent: 19 December 2018 16:41
> To: 'Saku Ytti' ; Niall Donaghy 
> Cc: aaron.dew...@gmail.com; 'Juniper List' 
> Subject: RE: [j-nsp] ftp.juniper.net
> 
> Yep works, thanks (Niall, use sftp.juniper.net not ftp.juniper.net)
> 
> C:\Users\aaron>sftp anonym...@sftp.juniper.net Password authentication
> Password:
> Connected to anonym...@sftp.juniper.net.
> sftp> pwd
> Remote working directory: /pub/incoming
> 
> - Aaron
> 
> 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ftp.juniper.net

[Aaron Dewell]

I thought it was pending shutdown in favor of sftp.  But I haven’t been paying 
that much attention.

> On Dec 19, 2018, at 8:44 AM, Aaron Gould  wrote:
> 
> Does juniper's ftp.juniper.net still work ?
> 
> 
> 
> I haven't been able to use it in a few weeks.
> 
> 
> 
> -Aaron
> 
> ___
> 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] JSU vs an X release

[Aaron Dewell]

Hi Adam,

A JSU is a point fix for one particular PR, and is tested against that PR.  If 
there's any risk for the fix affecting other things, it won't be considered a 
JSU candidate and you'll be asked to move to the next SR (or special, i.e. X 
release).  Thus, testing performed on a JSU is specific to that PR, but by 
their nature and approval process, no further regression is needed.  Thus, they 
can be delivered much faster.

Aaron

> On Jun 27, 2017, at 3:15 AM, adamv0...@netconsultings.com wrote:
> 
> Hi folks,
> 
> 
> 
> I'd like to gather your experience with fixing critical bug by a JSU vs an X
> release.
> 
> In IOS XR SMUs are BAU, but in Junos I'm not sure the JSU or JAM has a wide
> spread user base. 
> 
> And also there's the aspect of how much regression testing is done for JSU
> vs an X release.
> 
> 
> 
> adam 
> 
> 
> 
> netconsultings.com
> 
> ::carrier-class solutions for the telecommunications industry::
> 
> 
> 
> ___
> 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] in-band management interface vs. re firewall concepts/bcp

[Aaron Dewell]

Thus the standard practice has always been to protect lo0 with a firewall 
filter that just allows through the source IPs that you want.  There’s really 
no gain from using a VRF for it, though people with a Cisco background tend to 
expect it, thus why it’s being added now-ish.

> On Jul 8, 2016, at 12:31 PM, Jason Lixfeld  wrote:
> 
> That’s interesting.  I wouldn’t have expected to hear that about Juniper.
> 
> Thanks for the insight!
> 
>> On Jul 8, 2016, at 2:19 PM, Aaron Dewell  wrote:
>> 
>> 
>> Yes, though there are occasional issues such as sshd only binding to the 
>> local IPs within inet.0.  Whether that’s working yet or not will depend on 
>> version and the enhancement request previously mentioned.  Last I heard, 
>> that was going to be a 16.1 or farther out feature, but it depends on which 
>> daemon, which platform, and which release.  Doing management within a VRF is 
>> a new thing for Juniper and the feature is still in process of coming out.  
>> I would expect various issues with it, even if some things work.  
>> 
>>> On Jul 8, 2016, at 12:06 PM, Jason Lixfeld  wrote:
>>> 
>>> So if my management stations are is in the same VRF as lo0, no leaking 
>>> should be required.
>>> 
>>> Of course, this implies that the underpinnings of route redistribution 
>>> (i.e.: connected/static into MP-BGP) inside the VRF are all present, so the 
>>> routing table on the EX knows how to get everywhere inside that VRF.
>>> 
>>>> On Jul 8, 2016, at 1:52 PM, Aaron Dewell  wrote:
>>>> 
>>>> 
>>>> Sorry!  I got stuck on SRX.  Ignore that lol.
>>>> 
>>>> So if you’re only putting lo0 into the VRF, then you’ll need some way to 
>>>> route in and out of the VRF to get there.  That could be via route 
>>>> leaking, etc.  That routing table will have to have a return route to the 
>>>> source, and the main instance will have to have a route to that /32.  You 
>>>> can’t put the management interface (em0, fxp0, vme, etc. depending on 
>>>> platform) into a VRF.  
>>>> 
>>>> As you’re route-leaking or whatever in order to get back and forth into 
>>>> the VRF, it really doesn’t buy you much on a Junos platform to put it 
>>>> there in the first place.  Thus, why nobody really does it in 
>>>> Juniper-land.  You could, in theory, only leak your management routes into 
>>>> the VRF and increase your security slightly, but you can also just filter 
>>>> source IPs in your lo0 filter with the same benefit.
>>>> 
>>>> You still get the same firewall filter protection (the input-list stuff) 
>>>> if it’s in the main inet.0 instance.  
>>>> 
>>>> So the common practice is to write the lo0 filter like this:
>>>> 
>>>> from a prefix list listing allowed sources using particular protocols 
>>>> (i.e. ssh) -> accept
>>>> anything else -> discard
>>>> 
>>>> That can be multiple terms or however you prefer to write it.  
>>>> 
>>>>> On Jul 8, 2016, at 11:34 AM, Jason Lixfeld  wrote:
>>>>> 
>>>>> Sorry, I wasn’t trying to suggest I got an error, it was more of a 
>>>>> conceptual config paste.
>>>>> 
>>>>> This is on an EX9200, which I don’t think support security zones?
>>>>> 
>>>>>> On Jul 8, 2016, at 1:25 PM, Aaron Dewell  wrote:
>>>>>> 
>>>>>> 
>>>>>> Did you write those firewall filters that you list?  What was the error 
>>>>>> that you got?
>>>>>> 
>>>>>> You’ll have to assign lo0 into a security zone, that might be what’s 
>>>>>> missing.  
>>>>>> 
>>>>>> "security zones functional-zone management” must be in inet.0.  You can 
>>>>>> do other zones in a VRF and do in-band management within them (though 
>>>>>> it’s slightly recommended against, due to potential of misconfiguration 
>>>>>> causing a security issue), but this should work.  That’s what Clinton 
>>>>>> was saying.  
>>>>>> 
>>>>>>> On Jul 8, 2016, at 11:20 AM, Jason Lixfeld  
>>>>>>> wrote:
>>>>>>> 
>>>>>>> I’m not quite following.  This won’t work:
>>>>>>> 
>>>>>>> set interfaces lo0 unit 0 family inet address 10.219.60.54/32
>>&

Re: [j-nsp] in-band management interface vs. re firewall concepts/bcp

[Aaron Dewell]

Yes, though there are occasional issues such as sshd only binding to the local 
IPs within inet.0.  Whether that’s working yet or not will depend on version 
and the enhancement request previously mentioned.  Last I heard, that was going 
to be a 16.1 or farther out feature, but it depends on which daemon, which 
platform, and which release.  Doing management within a VRF is a new thing for 
Juniper and the feature is still in process of coming out.  I would expect 
various issues with it, even if some things work.  

> On Jul 8, 2016, at 12:06 PM, Jason Lixfeld  wrote:
> 
> So if my management stations are is in the same VRF as lo0, no leaking should 
> be required.
> 
> Of course, this implies that the underpinnings of route redistribution (i.e.: 
> connected/static into MP-BGP) inside the VRF are all present, so the routing 
> table on the EX knows how to get everywhere inside that VRF.
> 
>> On Jul 8, 2016, at 1:52 PM, Aaron Dewell  wrote:
>> 
>> 
>> Sorry!  I got stuck on SRX.  Ignore that lol.
>> 
>> So if you’re only putting lo0 into the VRF, then you’ll need some way to 
>> route in and out of the VRF to get there.  That could be via route leaking, 
>> etc.  That routing table will have to have a return route to the source, and 
>> the main instance will have to have a route to that /32.  You can’t put the 
>> management interface (em0, fxp0, vme, etc. depending on platform) into a 
>> VRF.  
>> 
>> As you’re route-leaking or whatever in order to get back and forth into the 
>> VRF, it really doesn’t buy you much on a Junos platform to put it there in 
>> the first place.  Thus, why nobody really does it in Juniper-land.  You 
>> could, in theory, only leak your management routes into the VRF and increase 
>> your security slightly, but you can also just filter source IPs in your lo0 
>> filter with the same benefit.
>> 
>> You still get the same firewall filter protection (the input-list stuff) if 
>> it’s in the main inet.0 instance.  
>> 
>> So the common practice is to write the lo0 filter like this:
>> 
>> from a prefix list listing allowed sources using particular protocols (i.e. 
>> ssh) -> accept
>> anything else -> discard
>> 
>> That can be multiple terms or however you prefer to write it.  
>> 
>>> On Jul 8, 2016, at 11:34 AM, Jason Lixfeld  wrote:
>>> 
>>> Sorry, I wasn’t trying to suggest I got an error, it was more of a 
>>> conceptual config paste.
>>> 
>>> This is on an EX9200, which I don’t think support security zones?
>>> 
>>>> On Jul 8, 2016, at 1:25 PM, Aaron Dewell  wrote:
>>>> 
>>>> 
>>>> Did you write those firewall filters that you list?  What was the error 
>>>> that you got?
>>>> 
>>>> You’ll have to assign lo0 into a security zone, that might be what’s 
>>>> missing.  
>>>> 
>>>> "security zones functional-zone management” must be in inet.0.  You can do 
>>>> other zones in a VRF and do in-band management within them (though it’s 
>>>> slightly recommended against, due to potential of misconfiguration causing 
>>>> a security issue), but this should work.  That’s what Clinton was saying.  
>>>> 
>>>>> On Jul 8, 2016, at 11:20 AM, Jason Lixfeld  wrote:
>>>>> 
>>>>> I’m not quite following.  This won’t work:
>>>>> 
>>>>> set interfaces lo0 unit 0 family inet address 10.219.60.54/32
>>>>> set interfaces lo0 unit 0 family inet filter input-list 
>>>>> V4-ACCEPT-COMMON-SERVICES
>>>>> set interfaces lo0 unit 0 family inet filter input-list 
>>>>> V4-ACCEPT-ESTABLISHED
>>>>> set interfaces lo0 unit 0 family inet filter input-list V4-DISCARD-ALL
>>>>> set routing-instances MANAGEMENT instance-type vrf
>>>>> set routing-instances MANAGEMENT interface lo0.0
>>>>> set routing-instances MANAGEMENT route-distinguisher 21949:21949
>>>>> set routing-instances MANAGEMENT vrf-target target:21949:21949
>>>>> 
>>>>>> On Jul 7, 2016, at 6:07 PM, Clinton Work  wrote:
>>>>>> 
>>>>>> I would still use lo0.0 as your always up in-band mgmt interface.  
>>>>>> JunOS doesn't support putting management into a routing-instance and I
>>>>>> have been pushing Juniper for this.   You can use inet.0 for management
>>>>>> and additional logical routers for data traffic, but that is different
>>>>>> than a Ci

Re: [j-nsp] in-band management interface vs. re firewall concepts/bcp

[Aaron Dewell]

Sorry!  I got stuck on SRX.  Ignore that lol.

So if you’re only putting lo0 into the VRF, then you’ll need some way to route 
in and out of the VRF to get there.  That could be via route leaking, etc.  
That routing table will have to have a return route to the source, and the main 
instance will have to have a route to that /32.  You can’t put the management 
interface (em0, fxp0, vme, etc. depending on platform) into a VRF.  

As you’re route-leaking or whatever in order to get back and forth into the 
VRF, it really doesn’t buy you much on a Junos platform to put it there in the 
first place.  Thus, why nobody really does it in Juniper-land.  You could, in 
theory, only leak your management routes into the VRF and increase your 
security slightly, but you can also just filter source IPs in your lo0 filter 
with the same benefit.

You still get the same firewall filter protection (the input-list stuff) if 
it’s in the main inet.0 instance.  

So the common practice is to write the lo0 filter like this:

from a prefix list listing allowed sources using particular protocols (i.e. 
ssh) -> accept
anything else -> discard

That can be multiple terms or however you prefer to write it.  

> On Jul 8, 2016, at 11:34 AM, Jason Lixfeld  wrote:
> 
> Sorry, I wasn’t trying to suggest I got an error, it was more of a conceptual 
> config paste.
> 
> This is on an EX9200, which I don’t think support security zones?
> 
>> On Jul 8, 2016, at 1:25 PM, Aaron Dewell  wrote:
>> 
>> 
>> Did you write those firewall filters that you list?  What was the error that 
>> you got?
>> 
>> You’ll have to assign lo0 into a security zone, that might be what’s 
>> missing.  
>> 
>> "security zones functional-zone management” must be in inet.0.  You can do 
>> other zones in a VRF and do in-band management within them (though it’s 
>> slightly recommended against, due to potential of misconfiguration causing a 
>> security issue), but this should work.  That’s what Clinton was saying.  
>> 
>>> On Jul 8, 2016, at 11:20 AM, Jason Lixfeld  wrote:
>>> 
>>> I’m not quite following.  This won’t work:
>>> 
>>> set interfaces lo0 unit 0 family inet address 10.219.60.54/32
>>> set interfaces lo0 unit 0 family inet filter input-list 
>>> V4-ACCEPT-COMMON-SERVICES
>>> set interfaces lo0 unit 0 family inet filter input-list 
>>> V4-ACCEPT-ESTABLISHED
>>> set interfaces lo0 unit 0 family inet filter input-list V4-DISCARD-ALL
>>> set routing-instances MANAGEMENT instance-type vrf
>>> set routing-instances MANAGEMENT interface lo0.0
>>> set routing-instances MANAGEMENT route-distinguisher 21949:21949
>>> set routing-instances MANAGEMENT vrf-target target:21949:21949
>>> 
>>>> On Jul 7, 2016, at 6:07 PM, Clinton Work  wrote:
>>>> 
>>>> I would still use lo0.0 as your always up in-band mgmt interface.  
>>>> JunOS doesn't support putting management into a routing-instance and I
>>>> have been pushing Juniper for this.   You can use inet.0 for management
>>>> and additional logical routers for data traffic, but that is different
>>>> than a Cisco management VRF.   
>>>> 
>>>> JunOS doesn't have an explicit control-plane interface and you attach
>>>> your control-plane filter to lo0.0 instead.   
>>>> 
>>>> --
>>>> Clinton Work
>>>> Airdrie, AB
>>>> 
>>>> On Thu, Jul 7, 2016, at 11:52 AM, Jason Lixfeld wrote:
>>>>> Hey there,
>>>>> 
>>>>> Coming from a Cisco background, I generally assign a loopback interface
>>>>> as my in-band management channel.  I stick that into my management VRF
>>>>> and that’s that.  Without knowing any better, my instinct would be to do
>>>>> the same in JunOS, but it seems as though lo0 is the control plane
>>>>> interface between user space and the re.  That feels somewhat different
>>>>> to me, because the Cisco equivalent is generally the control-plane
>>>>> “interface”.
>>>> 
>>>>> 
>>>>> So my question is what the best common practise is for an always-up,
>>>>> in-band management channel on JunOS in an exclusively L3 environment
>>>>> (i.e.:  no vlan or irb interfaces used at all in the system) without
>>>>> fully understanding whether that could also be lo0.0, or whether it
>>>>> should be lo0.somethingelse, or whether it should be something else
>>>>> entirely.
>>>> ___
>>>> 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] in-band management interface vs. re firewall concepts/bcp

[Aaron Dewell]

Did you write those firewall filters that you list?  What was the error that 
you got?

You’ll have to assign lo0 into a security zone, that might be what’s missing.  

"security zones functional-zone management” must be in inet.0.  You can do 
other zones in a VRF and do in-band management within them (though it’s 
slightly recommended against, due to potential of misconfiguration causing a 
security issue), but this should work.  That’s what Clinton was saying.  

> On Jul 8, 2016, at 11:20 AM, Jason Lixfeld  wrote:
> 
> I’m not quite following.  This won’t work:
> 
> set interfaces lo0 unit 0 family inet address 10.219.60.54/32
> set interfaces lo0 unit 0 family inet filter input-list 
> V4-ACCEPT-COMMON-SERVICES
> set interfaces lo0 unit 0 family inet filter input-list V4-ACCEPT-ESTABLISHED
> set interfaces lo0 unit 0 family inet filter input-list V4-DISCARD-ALL
> set routing-instances MANAGEMENT instance-type vrf
> set routing-instances MANAGEMENT interface lo0.0
> set routing-instances MANAGEMENT route-distinguisher 21949:21949
> set routing-instances MANAGEMENT vrf-target target:21949:21949
> 
>> On Jul 7, 2016, at 6:07 PM, Clinton Work  wrote:
>> 
>> I would still use lo0.0 as your always up in-band mgmt interface.  
>> JunOS doesn't support putting management into a routing-instance and I
>> have been pushing Juniper for this.   You can use inet.0 for management
>> and additional logical routers for data traffic, but that is different
>> than a Cisco management VRF.   
>> 
>> JunOS doesn't have an explicit control-plane interface and you attach
>> your control-plane filter to lo0.0 instead.   
>> 
>> --
>> Clinton Work
>> Airdrie, AB
>> 
>> On Thu, Jul 7, 2016, at 11:52 AM, Jason Lixfeld wrote:
>>> Hey there,
>>> 
>>> Coming from a Cisco background, I generally assign a loopback interface
>>> as my in-band management channel.  I stick that into my management VRF
>>> and that’s that.  Without knowing any better, my instinct would be to do
>>> the same in JunOS, but it seems as though lo0 is the control plane
>>> interface between user space and the re.  That feels somewhat different
>>> to me, because the Cisco equivalent is generally the control-plane
>>> “interface”.
>> 
>>> 
>>> So my question is what the best common practise is for an always-up,
>>> in-band management channel on JunOS in an exclusively L3 environment
>>> (i.e.:  no vlan or irb interfaces used at all in the system) without
>>> fully understanding whether that could also be lo0.0, or whether it
>>> should be lo0.somethingelse, or whether it should be something else
>>> entirely.
>> ___
>> 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] Help with routing-instance bgp session

[Aaron Dewell]

Sure, the neighborship must be within the routing-instance because that’s where 
the neighbor is connected.  I don’t believe you can create a peer using a 
leaked route.

I don’t believe rib-groups will solve this either, but I’m not certain.  It is 
worth the attempt, but I am not confident of the success.

> On Jul 4, 2016, at 9:11 PM, Eduardo Schoedler  wrote:
> 
> Hi Aaron,
> 
> Perhaps can I do this using rib-groups within bgp neighbor family inet
> unicast knob?
> 
> I also tried declare bgp neighbor in main table, but even leaking
> connected routes, they say "No route to host" but the routes are
> there.
> 
> Thanks.
> 
> 2016-07-05 0:07 GMT-03:00 Aaron Dewell :
>> 
>> The routes have to exist in the table in order to be available to a policy.  
>> So you’ll have to leak them first.
>> 
>> Any policy only has access to the routes within it’s context.
>> 
>> You could route them to discard after they are leaked however.  That way, 
>> they still exist even if they are inactive.  (see the advertise-inactive 
>> knob).
>> 
>>> On Jul 4, 2016, at 9:02 PM, Eduardo Schoedler  wrote:
>>> 
>>> Can I announce all prefixes from main table in a bgp session that is
>>> into a routing-instance? I can't leak the prefixes, only advertise
>>> them, because it's a looking glass session, like Routeviews.
>>> 
>>> All tips are welcome.
>>> 
>>> Thank you.
>>> 
>>> Regards,
>>> 
>>> --
>>> Eduardo Schoedler
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> 
> 
> 
> -- 
> Eduardo Schoedler

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Help with routing-instance bgp session

[Aaron Dewell]

The routes have to exist in the table in order to be available to a policy.  So 
you’ll have to leak them first.

Any policy only has access to the routes within it’s context.

You could route them to discard after they are leaked however.  That way, they 
still exist even if they are inactive.  (see the advertise-inactive knob).

> On Jul 4, 2016, at 9:02 PM, Eduardo Schoedler  wrote:
> 
> Can I announce all prefixes from main table in a bgp session that is
> into a routing-instance? I can't leak the prefixes, only advertise
> them, because it's a looking glass session, like Routeviews.
> 
> All tips are welcome.
> 
> Thank you.
> 
> Regards,
> 
> -- 
> 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

Re: [j-nsp] Anybody have an SRX working with Comcast DHCP v4 and v6?

[Aaron Dewell]

I attempted to make this work on an SRX210 running 12.1X46-D30 with TWC.  The 
inherent issue was that Junos will only accept multiples of 16 bit-boundaries 
as a dhcpv6 client, and /56 (as TWC assigns) is not accepted.

So it’s less about your settings and more about the known PR, assuming that 
Comcast is delegating a /56 as TWC does.

That known PR doesn’t mean that “prefix delegation is just broken”, it just 
means that it needs to be able to accept a /56 to operate on a residential 
cable network.  If they sent you a /48 or a /80, it would just work.  :)

> On Jul 1, 2016, at 10:17 PM, Chuck Cox  wrote:
> 
> I have Comcast residential service at home terminating on an Arris
> SB6121 modem. The Ethernet side of the modem is cabled to fe-0/0/0 on
> an SRX-100B running 12.1X46-D40.2 (unfortunately the last code release
> that will run on an SRX-100B due to its limited RAM).
> 
> DHCPv4 works fine. Comcast assigns a public v4 address for fe-0/0/0/.0
> and I can access anything v4 by source NATing from my LAN
> (192.168.x.x) to the v4 interface IP on fe-0/0/0.0.
> 
> DHCPv6 just sits in the init state and never gets an address
> assignment, so the only v6 address on fe-0/0/0.0 is an fe80:: link
> local address. I've experimented with several combinations of DHCPv6
> settings but no joy.
> 
> I've done some Googling and saw several discussions about how prefix
> delegation on SRX had issues for a long time and might be fixed now,
> but I'm not even getting that far. If any body knows the magic
> combination of client-type, client-ia-type, client-identifier, etc. to
> get an SRX to play nice with Comcast, a little help would be greatly
> appreciated. Relevant details on my current setup are below.
> 
> Thanks,
> Chuck
> 
> 
> 
>> show configuration interfaces fe-0/0/0
> unit 0 {
>family inet {
>dhcp-client;
>}
>family inet6 {
>dhcpv6-client {
>client-type statefull;
>client-ia-type ia-na;
>client-identifier duid-type duid-ll;
>retransmission-attempt 6;
>}
>}
> }
> 
>> show configuration security zones security-zone untrust
> screen untrust-screen;
> interfaces {
>fe-0/0/0.0 {
>host-inbound-traffic {
>system-services {
>ping;
>dhcp;
>dhcpv6;
>}
>protocols {
>router-discovery;
>}
>}
>}
> }
> 
>> show dhcpv6 client binding detail
> Client Interface: fe-0/0/0.0
> Hardware Address: 50:c5:8d:2f:de:40
> State:INIT(DHCPV6_CLIENT_STATE_INIT)
> ClientType:   STATEFUL
> Bind Type:IA_NA
> Client DUID:  LL0x3-50:c5:8d:2f:de:40
> Rapid Commit: Off
> Server Ip Address:::/0
> Client IP Address:::/0
> ___
> 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 Active/Active

[Aaron Dewell]

> On Jun 27, 2016, at 9:16 AM, Hugo Slabbert  wrote:
> 
> 
> On Sun 2016-Jun-26 20:51:41 -0700, Brian Spade  wrote:
> 
>> Hi Alexandre,
>> 
>> Thanks for all the details.  I will check with our Juniper team and see
>> what's the latest on A/A vs A/P.  For most of our sites, we plan to just
>> use A/P.  But for the largest sites with multi-10Gbps egress, we want to
>> try A/A.
> 
> Aside from the other option listed of splitting the cluster into separate 
> nodes, if your goal is multi-10G egress, you could also LAG 10G interfaces on 
> the SRX northbound.  The config isn't super intuitive, but you can LAG reth 
> child members in an A/P setup.


It’s not that bad.  It’s just keeping in mind that it’s really two LAGs, one to 
each cluster member.  So it’s configured twice on the switch, but only once on 
the SRX cluster.  Odd, but it makes sense in the end.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX Active/Active

[Aaron Dewell]

Hi Brian,

Those all are good mitigation steps for an RG0 failover.  There are some 
caveats about graceful restart on the SRXs, but those should have been fixed a 
while ago.  Just to be sure, I’d get a recommendation on Junos version from 
your local SE.

Another option is to not use a cluster at all, and make them active/active via 
routing protocols.  Then, a control plane failure only kills one side.  But 
then failovers are stateless which has more impact.

However, control plane failures are rare, so it’s chasing a very small 
probability in the end.

Aaron

> On Jun 26, 2016, at 12:40 PM, Brian Spade  wrote:
> 
> Hi Aaron,
> 
> On Sun, Jun 26, 2016 at 11:19 AM, Aaron Dewell  <mailto:aaron.dew...@gmail.com>> wrote:
> >
> > You are correct - RG0 will always be active/passive.  A full control plane 
> > failover will always be painful.
> >
> > SRX active/active is more about the interfaces in use.  You can arrange for 
> > half of your traffic to prefer FW1 vs. FW2 and achieve active/active in 
> > that way so you’ll take less of a hit when an interface fails (or a 
> > neighbor device goes down).  So that’s really what you are protecting 
> > against, which seems like you’ve done that.
> >
> 
> Thanks for your feedback.  It will be a lot of configuration, but was 
> thinking I could do the following to limit RG0 failure (or southbound Core 
> failure):
> /31 transit VLAN per link (per VRF).  So the total number of /31 transit's 
> needed will be 4 * # of VRFs (28 /31's in my case).
> Graceful restart configured on the SRX to limit RG0 failure.
> Core1 failure (or Core2 failure) should be limited with graceful restart and 
> all uplinks having an OSPF adjacencies.
> Anyways, just wondering your thoughts on this.  I will probably just have to 
> lab it to see how it performs.
> 
> If active/active is not a good way, I might have to add in two MX border 
> routers... That seems like a waste since I just need a default route via BGP.
> 
> Thanks.
> /bs
> 
> >> On Jun 26, 2016, at 12:15 PM, Brian Spade  >> <mailto:bitkr...@gmail.com>> wrote:
> >>
> >> Hi,
> >>
> >> I'm trying to figure out the best way to setup an SRX cluster as
> >> active/active.  I have attached a diagram of the topology, but it's a
> >> full mesh of links.  The ISP links are local interfaces and the
> >> southbound interfaces to the core routers are reth's.  Core1 is HSRP
> >> primary for all VLANs.  FW1 is primary for RG1 and FW2 is primary for
> >> RG2.  The IGP is OSPF but have many VRFs that are connected to the FW
> >> with transit VLANs to bind the sub-interface to virtual router & zone.
> >>
> >> The issue I have is Core2 has no active OSPF neighbors in this setup.
> >> Therefore, if Core1 fails, there will be a control outage as Core2
> >> establishes OSPF adjacencies.
> >>
> >> So I'm thinking it might be better to remove the reth's and use local
> >> interfaces on the FW/CORE links.  This way I can have a full mesh of
> >> OSPF adjacencies and no control plane loss when Core1 fails.
> >>
> >> Does anyone have thoughts on this or recommend the best way to achieve
> >> this active/active full mesh setup?  If there's good reason to not use
> >> active/active, I'd welcome the feedback.
> >>
> >> Thanks.
> >> /bs
> >> ___
> >> juniper-nsp mailing list juniper-nsp@puck.nether.net 
> >> <mailto:juniper-nsp@puck.nether.net>
> >> https://puck.nether.net/mailman/listinfo/juniper-nsp 
> >> <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 Active/Active

[Aaron Dewell]

You are correct - RG0 will always be active/passive.  A full control plane 
failover will always be painful.

SRX active/active is more about the interfaces in use.  You can arrange for 
half of your traffic to prefer FW1 vs. FW2 and achieve active/active in that 
way so you’ll take less of a hit when an interface fails (or a neighbor device 
goes down).  So that’s really what you are protecting against, which seems like 
you’ve done that.

> On Jun 26, 2016, at 12:15 PM, Brian Spade  wrote:
> 
> Hi,
> 
> I'm trying to figure out the best way to setup an SRX cluster as
> active/active.  I have attached a diagram of the topology, but it's a
> full mesh of links.  The ISP links are local interfaces and the
> southbound interfaces to the core routers are reth's.  Core1 is HSRP
> primary for all VLANs.  FW1 is primary for RG1 and FW2 is primary for
> RG2.  The IGP is OSPF but have many VRFs that are connected to the FW
> with transit VLANs to bind the sub-interface to virtual router & zone.
> 
> The issue I have is Core2 has no active OSPF neighbors in this setup.
> Therefore, if Core1 fails, there will be a control outage as Core2
> establishes OSPF adjacencies.
> 
> So I'm thinking it might be better to remove the reth's and use local
> interfaces on the FW/CORE links.  This way I can have a full mesh of
> OSPF adjacencies and no control plane loss when Core1 fails.
> 
> Does anyone have thoughts on this or recommend the best way to achieve
> this active/active full mesh setup?  If there's good reason to not use
> active/active, I'd welcome the feedback.
> 
> Thanks.
> /bs
> ___
> 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] access-internal routes

[Aaron Dewell]

Any DHCP routes appear as access-internal.  There may be other reasons but 
that’s the most common.

> On Mar 30, 2016, at 5:46 PM, Aaron  wrote:
> 
> what are these routes (access-internal) ?  i'm seeing them actually being
> sent over my MPLS L3VPN into my other pe's as /32 routes.  very interesting.
> and seemingly very inefficient and busy.  not sure that I like the idea of
> host routes for 10's of thousands of hosts being injected into my mpls vpn
> all over my network.  i'm thinking this is happening possible from dhcp
> relay on my acx5048.  how do I turn off the /32 route injection at the
> acx5048 ?
> 
> 
> 
> 
>  URL=mailto%3aagould%40eng-lab-acx5048-1> agould@eng-lab-acx5048-1> show
> route table one.inet.0 protocol access-internal
> one.inet.0: 768 destinations, 956 routes (768 active, 0 holddown, 0 hidden)
> + = Active Route, - = Last Active, * = Both
> 10.88.127.51/32*[Access-internal/12] 22:44:14
>> to 111.222.176.65 via irb.10
> 111.222.176.75/32 *[Access-internal/12] 00:06:28
>> to 111.222.176.65 via irb.10
> 
> 
> 
> 
>  URL=mailto%3aagould%40eng-lab-acx5048-1> agould@eng-lab-acx5048-1> show dhcp
> relay binding routing-instance one
> IP addressSession Id  Hardware address   Expires State
> Interface
> 10.88.127.51  3   38:c8:5c:2a:c8:bf  3551BOUND
> irb.10
> 111.222.176.7513  94:de:80:a4:65:ad  12130   BOUND
> irb.10
> 
> 
> 
> 
> 
> other cisco asr9k pe's within my mpls cloud sees these /32 routes...
> 
> 
> 
> RP/0/RSP0/CPU0:sabn-9k#sh route vrf one | in 10.101.12.245
> Wed Mar 30 14:47:00.638 CDT
> B10.88.127.51/32 [200/0] via 10.101.12.245 (nexthop in vrf default),
> 05:46:47
> B111.222.176.64/28 [200/0] via 10.101.12.245 (nexthop in vrf default),
> 05:36:21
> B111.222.176.75/32 [200/0] via 10.101.12.245 (nexthop in vrf default),
> 00:08:42
> 
> 
> 
> Aaron
> 
> 
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] juniper hack news

[Aaron Dewell]

While that may be completely correct (while not completely provable, it is 
entirely reasonable to assume it), the immediate question was whether this 
particular vulnerability affected JunOS also, or only ScreenOS.

The answer to that more narrow question is that it only affects ScreenOS.

I think we can assume that most of the software we use today (Windows, MacOS, 
IOS, JunOS, Linux, FreeBSD, etc.) all contain some form of government-induced 
weakness.  Exactly what those are have yet to be discovered.  I for one am 
confident that they all contain at least one if not many.  

However, the question asked only concerned this particular vulnerability, for 
which JunOS is not affected.  The malicious code in question was introduced 
into ScreenOS source code and not into JunOS.

> On Dec 26, 2015, at 3:21 PM, Chris Cappuccio  wrote:
> 
> Hugo Slabbert [h...@slabnet.com] wrote:
>> 
>> Am I missing something that indicates this is known to affect Junos as well?
>> 
> 
> I just gave you a link to a formal NSA/GCHQ "TOP SECRET" documentation -- from
> 2011 -- which says they are DOING IT. It only takes NSA ~90 days to develop
> a new vulnerability in this class of software.
> 
> I think the best we can hope is that Juniper was privately informed and has
> quietly patched any JunOS vulnerabilities.
> 
> Juniper has a lot of international business to lose from public
> vulnerabilities in core Internet infrastructure. Cisco already took a large
> hit.
> 
> I don't know what else to say. Anyone who thinks that the NSA did not develop
> this capability in 2011 needs to read. Anyone who thinks NSA can't develop
> this capability again (once their old vulnerabilities are burned) does not
> understand the class of this attacker.
> ___
> 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] Limit on interfaces in bundle

[Aaron Dewell]

It's code version dependent. It was raised recently, so if you still see 16
you need to upgrade.
On Oct 29, 2015 5:01 AM, "Cydon Satyr"  wrote:

> Hello experts,
>
> Could somebody confirm if 16 is the max number of physical interfaces one
> can have in a LAG on MX? What about MX2020, is it still 16, or is it
> possible to have more than that?
>
> So far I've see 16 is max on every MX platform but I heard someone
> mentioned it could go higher.
>
> Best regards to all
> ___
> 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] purpose of "commit check"?

[Aaron Dewell]

Yes, the commit will fail if commit check would have also failed.  I tend to 
use commit check as a check on myself when I’ve done a big cut-and-paste, or 
when creating a bunch of objects.  The time to fail of commit check is less 
than commit if there are discrepancies.  

On Sep 28, 2015, at 3:32 PM, Brad Fleming  wrote:
> I use it to make sure another admin hasn’t made changes overtop of mine. 
> Also, I believe commit check can help in situations where you are using “edit 
> private”.
> 
> 
>> On Sep 28, 2015, at 4:24 PM, Martin T  wrote:
>> 
>> Hi,
>> 
>> when I commit the candidate configuration in Junos, I tend to execute
>> "commit check" and if configuration check succeeds, then I execute
>> "commit comment ". However, when I think about it, "commit
>> (comment)" itself should perform those very same checks that "commit
>> check" does. If yes, then what is the point of "commit check"? Only
>> purpose I could see is to check the validity of the candidate
>> configuration in the middle of the configuration process, i.e. to
>> check if the changes made in candidate configuration so far are fine
>> but the candidate configuration is not ready to be committed.
>> 
>> 
>> thanks,
>> Martin
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Disable telnet/ssh access from virtual routers

[Aaron Dewell]

Apply a filter on lo0.0 which denies traffic from anything but your management 
IPs.  Or, put a filter on the VR interface denying all traffic destined to that 
IP itself.  

On Jul 15, 2015, at 10:11 AM, Victor Sudakov  wrote:
> Colleagues,
> 
> I have customers' networks connected to routing-instances of type
> "virtual-router." These routing-instances are supposed to be isolated
> and use their own address space.
> 
> However, a customer can telnet/ssh from their network to the
> virtual-router's IP address effectively telnetting to the main device. 
> 
> Is there an elegant way to prevent this from happening, i.e. to permit
> telnet/ssh access from hosts in the inet.0 table but deny from hosts
> from the CUSTOMERXX.inet.0 table?
> 
> Thanks in advance for any input.
> 
> -- 
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> sip:suda...@sibptus.tomsk.ru
> ___
> 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] Buying a used Juniper

[Aaron Dewell]

Ask your local reseller for a quote.

On May 5, 2015, at 2:13 PM, Colton Conor  wrote:
> Damien,
> 
> Thanks for the links. From the website: Juniper Networks, Inc. requires an
> inspection or a reinstatement fee for all products that were not originally
> purchased, by the then current owner of the equipment, from Juniper or an
> Authorized Juniper Partner. . Additionally, Juniper Networks, Inc. software
> is only licensed to the original purchaser and the license is not
> transferable. A re-registration fee is required to allow the legal use of
> the Juniper Networks, Inc. software. Please check re-registration fee
> pricing on the current Juniper Networks, Inc. Global Price List.
> 
> How does one obtain the global price list?
> 
> On Tue, May 5, 2015 at 12:58 PM, Damien DeVille 
> wrote:
> 
>> You guys might want to take a look at the following for Juniper's policies
>> on these matters.
>> 
>> http://kb.juniper.net/InfoCenter/index?page=content&id=KB9839
>> https://www.juniper.net/customers/support/downloads/7100156-001-EN.pdf
>> http://www.juniper.net/support/990222.pdf
>> 
>> 
>> 
>> - Damien
>> 
>> On Tue, May 5, 2015 at 1:29 PM, Colton Conor 
>> wrote:
>> 
>>> Correction, $500 per hour not $5000. So basically a one time fee of $2000.
>>> 
>>> On Tue, May 5, 2015 at 12:28 PM, Colton Conor 
>>> wrote:
>>> 
 Well, we have a smaller MX80 that doesn't have a support contract.
>>> Called
 JTAC with an issue, and they said the unit does not have a support
 contract. They said they have a one issue/call support fee of 4 hours at
 $5000 an hour which does not include software updates. So it does sound
 like they has some sort of oh you don't have a support contract one time
 help fee.
 
 What's the list price on a MX480-PREMIUM-AC Juniper Base system with
 redundant RE-2000, SCB, and power supplies?
 
 On Tue, May 5, 2015 at 12:00 PM, Raphael Mazelier 
 wrote:
 
> 
> 
> Le 05/05/15 18:47, Colton Conor a écrit :
> 
>> What are the limitations of buying a used Juniper MX router? I assume
>> there
>> will be no JTAC support, but what would it take to licenses a used
>>> router
>> to get JTAC support?
>> 
> 
> I don't know if juniper allow this, but if yes I think the price will
>>> be
> prohibitive :)
> 
> Does JTAC offer a one time support call fee for
>> unlicensed routers?
>> 
>> 
> I don't think so. And why Juniper will make this ? Juniper (as well as
> other network vendor) don't like grey market.
> 
> 
>> The router in question would be a MX480. Used, we can get them for
>>> under
>> 20K with redundant everything and 4 10G ports. New from Juniper I
>>> don't
>> even want to know what these would cost.
>> 
> 
> Lets try it. Juniper can make aggressive price :)
> 
> 
> --
> Raphael Mazelier
> 
> ___
> 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] Buying a used Juniper

[Aaron Dewell]

I looked into this once.  Support involves a one-time purchase of a contract, 
back-dated to when it was last under contract.  Depending on how long ago that 
was, it may be prohibitive as well.

On May 5, 2015, at 11:00 AM, Raphael Mazelier  wrote:
> 
> Le 05/05/15 18:47, Colton Conor a écrit :
>> What are the limitations of buying a used Juniper MX router? I assume there
>> will be no JTAC support, but what would it take to licenses a used router
>> to get JTAC support?
> 
> I don't know if juniper allow this, but if yes I think the price will be 
> prohibitive :)
> 
>> Does JTAC offer a one time support call fee for
>> unlicensed routers?
>> 
> 
> I don't think so. And why Juniper will make this ? Juniper (as well as other 
> network vendor) don't like grey market.
> 
>> 
>> The router in question would be a MX480. Used, we can get them for under
>> 20K with redundant everything and 4 10G ports. New from Juniper I don't
>> even want to know what these would cost.
> 
> Lets try it. Juniper can make aggressive price :)
> 
> 
> -- 
> Raphael Mazelier
> ___
> 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] non-split tunneling to SRX dynamic vpn with Pulse Secure client?

[Aaron Dewell]

Have you tried 0/1 and 128/1 instead of 0/0?

That’s also required for backup-router destination as well, so might solve this 
problem too.

On Mar 23, 2015, at 7:33 PM, Nick Schmalenberger  wrote:
> On Thu, Mar 05, 2015 at 06:29:30PM -0800, Nick Schmalenberger wrote:
>> I need to have my vpn clients default route go over their tunnel
>> to my SRX. Putting 0.0.0.0/0 as the remote-protected-resource
>> works for Windows clients 5.1r1.1-b52267, but with Mac Pulse
>> Secure is never able to setup a tunnel and connect. 
>> 
>> If I put some more specific routes, such as private addresses I
>> use internally and certain public addresses, as
>> remote-protected-resources, the Mac client (5.1r1.1-b52267 again)
>> is able to connect fine and reach all those networks/hosts with
>> the vpn assigned address, or NAT out of the same SRX in the case
>> of the public destinations (what I mostly want to do).
>> 
>> Does anyone else have that problem? Is there a known bug with the
>> Mac client? I made a support case with JTAC, and they agreed it
>> was a bug but said I need to call back and make a new case for
>> the Pulse Secure Client instead of SRX.
>> 
>> Another issue I had, was how to route the vpn clients assigned
>> private addresses, and give the route to OSPF. I made an
>> aggregate route for them, but it seemed like they weren't
>> contributing to bring it up, so I made a reject route for one of
>> the addresses in the network but not the pool. It worked, but the
>> clients couldn't connect to the srx itself. Any other
>> suggestions? A better action than reject for that? Thanks!
>> -Nick Schmalenberger
>> 
>> P.S. this post was very helpful in figuring it all out:
>> http://rtoodtoo.net/2013/10/01/jncie-sec-dynamic-vpn/
> 
> Juniper finally told me they reproduced this problem with the Mac
> client, but also that the configuration did NOT work with
> Windows! They then told me, the configuration is not supported at
> all, but I should try some other vpn client such as VPN Tracker,
> which I'm planning to do. It would then not use dynamic-vpn at
> all, but could still use the same xauth access-profile.
> 
> Meanwhile, I have also setup a site-to-site tunnel for some of
> the same usage, and it allows clients to use the remote SRX's dns
> proxy where dynamic-vpn clients could not (at least the way I
> managed to get it to work). So this will have some advantages as
> well. Thanks for the helpful suggestions!
> -Nick
> ___
> 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] QFX5100 3rd party optic/DAC

[Aaron Dewell]

What version of code? D10 (frs) had some issues with some cables which is
resolved in more current versions.

Also if this is 5100 to 4300 make sure you have auto negotiation turned off
on the 4300 (but that would probably fail with a juniper branded dac as
well so unlikely to be the issue).
On Sep 29, 2014 6:43 AM, "Darren O'Connor"  wrote:

> Anyone having any luck with this? I've got a few QSFP DACs that work
> perfectly fine on a 4300 stack, but the QFX5100 refuses to work with them.
> Work fine with a Juniper branded DAC.
>
>
>
> ___
> 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] Site to Site VPN issues with Cluster

[Aaron Dewell]

90% sure it's nested tunnels (GRE over IPSec).  You cannot do them in a cluster.

If you can get the Cisco side to remove the GRE layer and route directly over 
the secure tunnel (have not tried it so I don't know if they can or not), then 
it will work (using st0 on the SRX).  If you can't, your only workaround is to 
terminate that tunnel on something else (standalone SRX separate from the 
cluster, or something).

http://www.juniper.net/techpubs/en_US/junos12.1/information-products/topic-collections/release-notes/12.1/topic-64979.html

Buried in there (search for nested) is what you're looking for.

On May 8, 2014, at 10:53 PM, Morgan McLean wrote:
> Do you have an external zone to external zone allow rule? Obviously ike
> allowed for host inbound services as well for external.
> 
> Thanks,
> Morgan
> 
> 
> On Thu, May 8, 2014 at 1:04 PM, Levi Pederson <
> levipeder...@mankatonetworks.net> wrote:
> 
>> Greetings,
>> 
>> I've created several VPNs with little or no trouble in the past.  Between
>> both Cisco and Juniper devices.  But I am a little stumped by I cannot
>> connect a simple (Static IP) IPSec Tunnel between an SRX240 Cluster and a
>> single srx210.  I've checked the policies and the proposals and they are
>> spot on identical.  I've put the external interface on the cluster (lo0.0)
>> on the right external zone.  I'm also running OS 12.1.X44.D30 which
>> supports.  I've been reading several diatribes on how to place the loopback
>> into the redundancy and I have done that as well.  I'm still gathering the
>> configurations for perusal as they need to be secured.  First question
>> would be, does anything instantly pop out to anyone?  I'll have the configs
>> loaded as soon as I can.
>> 
>> 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


___
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

[Aaron Dewell]

I have terminated IPSec tunnels on reth interfaces entirely successfully.  I 
would think that would work fine in your setup as well.  It wasn't amazon, but 
it was to other remote SRXs.  The ISP in question did terminate on both cluster 
members (two drops).  

That was on a branch SRX.  On the 3400 YMMV but I don't see why it wouldn't 
work.  

On May 5, 2014, at 5:23 PM, Andy Litzinger 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] WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE

[Aaron Dewell]

fsck is run automatically every boot.  If the automatic fsck fails, it throws 
it to the backup partition.  So yes, you are correct, but the situation 
observed is when that system fails.

On Mar 24, 2014, at 11:04 PM, Victor Sudakov wrote:
> Dear Masood,
> 
> Thanks for the link to the KB article. 
> 
> However, being an old FreeBSD admin, I don't quite understand why and
> when a switch considers a partition "corrupted". It may be left in the
> dirty state due to a power loss, but this does not cause any
> corruption, especially when there were no writes during the power
> loss. The system just runs fsck and the partition should be as good
> as new.
> 
> Masood Ahmad Shah wrote:
>> Perhaps the file system became corrupted, most likely due to a sudden power
>> loss, or ungraceful shutdown. I would not worry, as long as both of the
>> partitions are healthy, then no issue with running switch on either of
>> them.
>> 
>> Just make sure that both of the partitions are healthy, so that fail over
>> can be done when needed. The following URL will point you how to recover
>> from this sort of condition. Just start from "Step-by-step recovery
>> procedure for this situation:" http://goo.gl/BoUUlA
>> 
>> Cheers,
>> Masood
>> 
>> On Fri, Mar 21, 2014 at 5:23 PM, Victor Sudakov  wrote:
>> 
>>> Colleagues,
>>> 
>>> What could be the reason that an EX4200-24T occasionally boots from the
>>> secondary copy?
>>> 
>>> If I "request system reboot slice alternate media internal", it will
>>> boot from the Active Partition all right. This means the Active
>>> Partition is operational, isn't it?
>>> 
>>> But sometimes, one day, the switch will eventually boot from the
>>> Backup Partition again.
>>> 
>>> What gives?
>>> 
>>> TIA for any ideas.
>>> 
>>> --
>>> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
>>> sip:suda...@sibptus.tomsk.ru
>>> ___
>>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>> 
> 
> -- 
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> sip:suda...@sibptus.tomsk.ru
> ___
> 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] TACACS in Junos

[Aaron Dewell]

The local username will be by default "remote" but you can return the TACACS 
version of a Vendor-Specific Attribute in order to specify something different 
per-user.  That local username then must exist on the router and all users 
which have that VSA returned will be mapped to that local user.

With your current setup, if you just create user remote with no password and a 
class of super-user (or whatever you prefer), it should solve the immediate 
problem.

On Mar 20, 2014, at 4:16 PM, Skeeve Stevens wrote:
> Hey all,
> 
> We've been implementing Tacacs on our networks and have this issue where we
> can't seem to get Tacacs working unless we declare the username and Tacacs
> is used just for the authentication.
> 
> Does anyone know how to get Tacacs working like Cisco where you just set it
> up and once you add users to the Tacacs back-end, they can login?
> 
> ...Skeeve
> 
> *Skeeve Stevens - *eintellego Networks Pty Ltd
> ske...@eintellegonetworks.com ; www.eintellegonetworks.com
> 
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> 
> facebook.com/eintellegonetworks ;  
> linkedin.com/in/skeeve
> 
> twitter.com/theispguy ; blog: www.theispguy.com
> 
> 
> The Experts Who The Experts Call
> Juniper - Cisco - Cloud - Consulting - IPv4 Brokering
> ___
> 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] IBGP via EBGP Default

[Aaron Dewell]

The route is known via some source, and therefore the destination is reachable. 
 I've never known the source of the route to matter for the peer address on any 
platform.

If you want it to go down, you can try the ttl knob to force it down if it's 
taking a longer path.

On Mar 17, 2014, at 12:55 PM, Christopher Costa wrote:
> We observe on EX and QFX platforms that their IBGP session is
> maintained (and reestablishes when bouncing the session) when the
> interconnect between them goes down; following an EBGP learned default
> route to reach the peer address.  Juniper says this is expected
> behavior, although my understanding is that the IBGP session should
> not be maintained when the underlying route is known via EBGP.  Am I
> mistaken about that?
> 
> Thanks
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Configuring in-band management over trunk interfaces in EX2200

[Aaron Dewell]

I can verify that if a VLAN is both named as a member and as a native-vlan-id, 
then it will accept traffic both tagged and untagged on that port for that 
VLAN.  However, traffic will only be sent tagged.  That can break some things 
(for example APs) which might work during boot but the loaded configuration 
after won't work.  The AP just stripped the tag during boot but did not do that 
after boot unless explicitly configured for tagging.

"all" means all defined VLANs on the switch.  AFAIK, if you have, say, one vlan 
defined, then setting "members my-vlan" and "members all" are functionally 
equivalent.  No tagged traffic to undefined VLANs would be accepted in either 
case.  The native-vlan-id issue remains the same either way I'm pretty sure.

On Mar 3, 2014, at 7:43 PM, Andrew Jones wrote:
> Paul,
> I would need to double-check the behaviour when 'all' is used for vlan 
> members, but certainly when a list of vlans are added as members of a trunk, 
> and then one of those is added as the native vlan as well, packets output on 
> the interface for that vlan (137 in your example), leave the interface with a 
> tag attached.
> 
> It may be that you were seeing this behaviour, and it could possibly be 
> worked around by using 'vlan members except 137' rather than 'vlan members 
> all'.
> 
>> show ethernet-switching interface ae0.0
> 
> Would show if this were the case.
> 
> Andrew
> 
> 
> On 28.02.2014 21:59, Paul S. wrote:
>> Mark,
>> 
>> It was the native-vlan-id, actually.
>> 
>> Removing it made it all start working.
>> 
>> Thank you!
>> 
>> On 2/28/2014 午後 07:58, Mark Tinka wrote:
>>> On Friday, February 28, 2014 12:31:00 PM Paul S. wrote:
>>> 
 However, if I move the unit 137 stanza from vlan.137
 directly to ae0 (Removing its trunk status in the
 process), and config it with vlan-tagging, and vlan-id
 137 -- it becomes accessible just fine, and can route
 traffic.
>>> On my EX4550's (and EX3200/4200's), the below works:
>>> 
>>> ae0 {
>>> description "SOMETHING";
>>> aggregated-ether-options {
>>> link-speed 10g;
>>> lacp {
>>> passive;
>>> }
>>> }
>>> unit 0 {
>>> description "SOMETHING";
>>> bandwidth 20g;
>>> family ethernet-switching {
>>> port-mode trunk;
>>> vlan {
>>> members all;
>>> }
>>> }
>>> }
>>> }
>>> 
>>> vlan {
>>> unit 999 {
>>> description "SOMETHING - Management VLAN";
>>> bandwidth 20g;
>>> family inet {
>>> filter {
>>> input filter-incoming;
>>> output filter-outgoing;
>>> }
>>> address a.b.c.d/30;
>>> }
>>> family iso;
>>> family inet6 {
>>> filter {
>>> input filter-incoming6;
>>> inactive: output filter-outgoing6;
>>> }
>>> address ::c:d::e/126;
>>> }
>>> }
>>> }
>>> 
>>> vlans {
>>> Edge-Network {
>>> vlan-id 999;
>>> l3-interface vlan.999;
>>> }
>>> }
>>> 
>>> Hope this helps.
>>> 
>>> Mark.
>> 
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VLAN's on EX4300 with 13.2X50-D15.3

[Aaron Dewell]

I don't know if I'd call them issues.  Just ELS introduces different 
configuration hierarchies that is the way things will be in the future.  The 
functionality is still there even if the config bits change some.

The main advantage of the 4300 vs. 4200 is 4x10G uplinks instead of 2, and 40G 
QSFP+ ports which can be either VC or routed.  It's a lot more flexible 
platform and much more compatible with others (read: QFX5100) than the EX4200 
will ever be.  

On Feb 19, 2014, at 2:36 PM, ryanL wrote:
> welp, i was about to pull the trigger and order the ex4300's for a new
> rack, but i think i'll stick to the ex4200 for now.
> 
> appreciative of people pointing out current issues (even tho i'm not the
> original poster).
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VLAN's on EX4300 with 13.2X50-D15.3

[Aaron Dewell]

It's a name change.  vlan is now irb.  It depends on platform, but the newer 
ones use irb instead of vlan.

So it doesn't work with vlan.103 because the vlan interface physically does not 
exist.  But you can configure nonexistent interfaces in JunOS.

On Feb 18, 2014, at 9:44 PM, Janusz Wełna wrote:
> Hi,
> 
> 
> Why when I have below config:
> 
>  ge-0/0/44 {
>description test;
>unit 0 {
>family ethernet-switching {
>vlan {
>members vlan103;
>}
>storm-control default;
> 
>   unit 103 {
>description test;
>family inet {
>address 10.46.163.1/29;
> 
> 
>vlan103 {
>description test;
>vlan-id 103;
>l3-interface vlan.103;
> 
> 
> 
> 
> I cannot ping from EX4300 10.46.163.1 and I cannot ping 10.46.163.1 from
> server connected to ge-0/0/44
> 
> 
> 
> 
> But when I add below:
> 
> 
> irb {
>unit 103 {
>family inet {
>address 10.46.163.1/29;
> 
> 
> and delete :
> 
> 
> vlan103 {
>description SGI;
>vlan-id 103;
>l3-interface vlan.103
> 
> 
> 
> 
> ping works correctly.
> 
> 
> On EX3300, EX4200 and EX2200 I not need setup irb interface, why I need on
> EX4300 ?
> 
> 
> 
> Br,
> 
> 
> Janusz
> ___
> 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] OSPF neig / SRX cluster / LACP

[Aaron Dewell]

reth interfaces are for failover not for bundle.  You can use two LAGs within a 
reth interface (multiple interface on a single node in a LAG) but not across 
both.  It's up (probably) because you aren't running LACP.  If you turn on 
LACP, then various links will be down.  I'm going to guess that's why the OSPF 
session from the right MX is down - because the MX is transmitting to the wrong 
node for that redundancy-group and it's being ignored.

On Jan 15, 2014, at 11:52 PM, Samol wrote:
> I can't access to the devices at the moment, but basically what we did
> was under each routing instance, we just put the interfaces inside the
> ospf area. very straight forward configuration of ospf. I have thought
> of links LAG from MX should only connect to each node individually.
> but it's interesting that LAG are running even though links are
> connected two different nodes (this is for Reth interface). But I
> tried to use AE interface on SRX cluster, the theory is true that we
> can't bundle two links that land on different node. we just can't
> commit.  that is the reason we move to Reth.
> 
> 
> Regards,
> 
> 
> 
> 
> 2014/1/16 Ben Dale :
>> I'm surprised that this is even working at all.
>> 
>> http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/interface-security-aggregated-ethernet-lacp-chassis-cluster-understanding.html
>> 
>> Specifically:
>> 
>> Note: The redundant Ethernet interface LAG child links from each node in the 
>> chassis cluster must be connected to a different LAG at the peer devices. If 
>> a single peer switch is used to terminate the redundant Ethernet interface 
>> LAG, two separate LAGs must be used in the switch.
>> 
>> From a single MX a single LAG should got to a single individual node from 
>> the chassis cluster.
>> 
>> Can you paste the OSPF configs from each RI on the SRX and MX-B?
>> 
>> On 16 Jan 2014, at 2:51 pm, Samol  wrote:
>> 
>>> what i'm doing is LACP (ae) from MX to LACP (reth) SRX where one link is on 
>>> Node0 and another is on node1. both link on SRX are member of Reth.
>>> 
>>> Admin@coolSRX# show interfaces reth1
>>> vlan-tagging;
>>> redundant-ether-options {
>>>redundancy-group 1;
>>>lacp {
>>>passive;
>>>periodic fast;
>>>}
>>> }
>>> 
>>> {primary:node0}[edit]
>>> Admin@coolSRX# run show lacp interfaces reth1
>>> Aggregated interface: reth1
>>>LACP state:   Role   Exp   Def  Dist  Col  Syn  Aggr  Timeout  
>>> Activity
>>>  ge-0/0/4   ActorNoNo   Yes  Yes  Yes   Yes Fast   
>>> Passive
>>>  ge-0/0/4 PartnerNoNo   Yes  Yes  Yes   Yes Fast
>>> Active
>>>  ge-9/0/4   ActorNoNo   Yes  Yes  Yes   Yes Fast   
>>> Passive
>>>  ge-9/0/4 PartnerNoNo   Yes  Yes  Yes   Yes Fast
>>> Active
>>>LACP protocol:Receive State  Transmit State  Mux State
>>>  ge-0/0/4  Current   Fast periodic Collecting 
>>> distributing
>>>  ge-9/0/4  Current   Fast periodic Collecting 
>>> distributing
>>> 
>>> All interfaces are UP. Reth's on SRX are also up. ae interfaces on MX-A and 
>>> B are also UP.
>>> 
>>> Regards,
>>> 
>>> 
>>> 
>>> 2014/1/16 Ben Dale 
>>> 
>>> On 16 Jan 2014, at 11:22 am, Samol  wrote:
 
 I got OSPF neighbor UP for all neighbors (RI: OUTSIDE and INSIDE) but not
 for Routing Instance (RI) INSIDE between SRX and MX-B. and If I shutdown
 interface on SRX-B (secondary) that connecting MX, all OSPF neighbors are
 UP.
 
>>> 
>>> Check it in layers:
>>> - is the reth interface on SRX-B definitely up when you have both links 
>>> enabled
>>> show chassis cluster interfaces
>>> - is your LACP up between MX-B and the cluster - bearing in mind that you 
>>> cannot have a single  LAG between MX-B and your SRX (it will need to be a 
>>> LAG to each cluster node)
>>> show lacp interfaces
>>> - if the neighbor is only down on one of the RIs, assuming you have a VLAN 
>>> between the MX and the SRX to carry each RI - double check that the VLAN is 
>>> actually tagged on both LAGs between the two boxes
>>> show bridge domain interface aex.0
>>> 
>>> Ben
>>> 
>>> 
>>> 
>>> --
>>> Samol Khoeurn
>>> (855) 077 55 64 02 / (855) 067 41 88 66
>>> Network Engineer
>>> Cisco: CCNA/CCNP SP/CCIP/
>>> Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT
>>> www.linkedin.com/in/samolkhoeurn
>>> 
>> 
> 
> 
> 
> -- 
> Samol Khoeurn
> (855) 077 55 64 02 / (855) 067 41 88 66
> Network Engineer
> Cisco: CCNA/CCNP SP/CCIP/
> Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT
> www.linkedin.com/in/samolkhoeurn
> 
> ___
> 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] OSPF neig / SRX cluster / LACP

[Aaron Dewell]

Depending on how you have your redundancy groups set up, only the active
links will be active at any given time. That means that the mxs won't see
two links active, they will see one each.  So you should have two
adjacencies on the srx and one on each mx in this scenario.

Lacp would only be useful with multiple links between the mx and the same
srx node. It does not help for failover between the two srx cluster
members.

I'm not sure this works in quite the way you are expecting.
On Jan 15, 2014 7:32 PM, "Samol"  wrote:

> Hi Experts,
>
> I'm running out of idea what else to try. I think it has something to do
> with clustering on SRX that makes ospf neigh never comes up. Let me explain
> you the scenario, I have two SRXs and two MXs. The two SRXs are clustered
> and two routing instances there, INSIDE and OUTSIDE. both MXs are also
> having two RI, INSIDE and OUTSIDE. RI OUSIDE on SRX connect to OUSIDE RI on
> MX. We got the physical connectivity like this :
>
> MX-A---SRX-A--MX-B
> MX-A---SRX-B--MX-B
>
> We basically have 4 ospf neig. LACP are between MX-A and SRX clustering ,
> same to MX-B and SRX cluster.
>
> MX-A INSIDE(irb)--(reth)INSIDE SRX
> OUTSIDE(reth)(irb)MX-B OUTSIDE
>
> MX-B INSIDE(irb)--(reth)INSIDE SRX
> OUTSIDE(reth)(irb)MX-A OUTSIDE
>
> I got OSPF neighbor UP for all neighbors (RI: OUTSIDE and INSIDE) but not
> for Routing Instance (RI) INSIDE between SRX and MX-B. and If I shutdown
> interface on SRX-B (secondary) that connecting MX, all OSPF neighbors are
> UP.
>
> Has anyone experience this ? I believe this must be caused by some features
> on SRX clustering things like LACP on Reth interfaces or so.
>
> would very appreciate for any comment.
>
>
> --
> Samol Khoeurn
> (855) 077 55 64 02 / (855) 067 41 88 66
> Network Engineer
> Cisco: CCNA/CCNP SP/CCIP/
> Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT
> www.linkedin.com/in/samolkhoeurn
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper MX5 Advice

[Aaron Dewell]

That's a pretty normal configuration so I wouldn't expect any issues.

Load balancing over both connections is another story entirely and doesn't 
matter the exact platform.  You can find a large volume of 
books/websites/opinions on BGP load balancing out there.  It's not exactly a 
trivial subject.  :-)

On Nov 25, 2013, at 3:21 PM, Jason Warren wrote:
> I am looking for some advise. I am looking at picking up two Juniper MX5's to 
> replace a Cisco 7206 Router that is acting as a BGP router. I am wanting to 
> run the Juniper's in as much of a HA or failover as can be. I have two BGP 
> connections to the outside world. My thought process so far is to terminate 
> one upstream BGP connection into each MX5. Then I was thinking of running a 
> physical link between the two MX5s and run a iBGP session . Then coming off 
> each MX5 would be a VRRP instance that would connect to the rest of my 
> network. This would allow all of my network to only know one default gateway 
> but hopefully allow the MX5's the capability of fully utilize both upstream 
> connections. Is there a better way or any 'gotchas' that comes to mind with 
> the above?
> ___
> 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] "community set" vs "community add"

[Aaron Dewell]

Depends if there are other communities attached besides vpls-z.  The first 
example would retain all of those.

If that's the only community on the route, then, in that case, they are the 
same.

On Oct 31, 2013, at 1:53 PM, Mihai wrote:
> Aren't these 2 policies  the same thing?
> 
> 
> policy-statement from-z {
> term 10 {
>  from {
>  protocol bgp;
>  community vpls-z;
>  }
>  then {
>  community delete vpls-z;
>  community add vpls-x;
>  accept;
>  }
>  }
> }
> 
> 
> 
> policy-statement from-z {
>  term 10 {
>  from {
>  protocol bgp;
>  community vpls-z;
>  }
>  then {
>  community set vpls-x;
>  accept;
>  }
>  }
> }
> 
> 
> 
> On 10/31/2013 08:46 PM, Chris Jones wrote:
>> set replaces all values with just the one specified.
>> add adds the specified community to the already existing list
>> 
>> 
>> On Thu, Oct 31, 2013 at 9:25 AM, Mihai > > wrote:
>> 
>>Hello,
>> 
>>  Using a simple topology with 2 PE's and one RR I am trying to
>>establish a vpls connection between PE's using different route-targets.
>>I am using the RR to rewrite the communities, but using "community
>>set" instead of "community add" results in a "No connections found"
>>message on both PE's.
>> 
>>x and z are PE's, q is RR
>> 
>>x> show configuration routing-instances mihai-vpls
>>instance-type vpls;
>>vlan-id 880;
>>interface ge-1/1/6.880;
>>route-distinguisher 10:10;
>>vrf-target target:10:10;
>>protocols {
>> vpls {
>> site a {
>> site-identifier 1;
>> }
>> }
>>}
>> 
>>z> show configuration routing-instances mihai-vpls
>>instance-type vpls;
>>vlan-id 880;
>>interface ge-1/1/7.980;
>>route-distinguisher 20:20;
>>vrf-target target:20:20;
>>protocols {
>> vpls {
>> site b {
>> site-identifier 2;
>> }
>> }
>>}
>> 
>>q# show policy-options
>>policy-statement from-z {
>> term 10 {
>> from {
>> protocol bgp;
>> community vpls-z;
>> }
>> then {
>> community set vpls-x;
>> accept;
>> }
>> }
>>}
>>policy-statement to-z {
>> term 10 {
>> from {
>> protocol bgp;
>> community vpls-x;
>> }
>> then {
>> community set vpls-z;
>> accept;
>> }
>> }
>>}
>>community vpls-x members target:10:10;
>>community vpls-z members target:20:20;
>> 
>>--__--__
>> 
>> 
>>x> show vpls connections
>>Layer-2 VPN connections:
>> 
>>Legend for connection status (St)
>>EI -- encapsulation invalid  NC -- interface encapsulation not
>>CCC/TCC/VPLS
>>EM -- encapsulation mismatch WE -- interface and instance encaps
>>not same
>>VC-Dn -- Virtual circuit downNP -- interface hardware not present
>>CM -- control-word mismatch  -> -- only outbound connection is up
>>CN -- circuit not provisioned<- -- only inbound connection is up
>>OR -- out of range   Up -- operational
>>OL -- no outgoing label  Dn -- down
>>LD -- local site signaled down   CF -- call admission control failure
>>RD -- remote site signaled down  SC -- local and remote site ID
>>collision
>>LN -- local site not designated  LM -- local site ID not minimum
>>designated
>>RN -- remote site not designated RM -- remote site ID not minimum
>>designated
>>XX -- unknown connection status  IL -- no incoming label
>>MM -- MTU mismatch   MI -- Mesh-Group ID not available
>>BK -- Backup connection  ST -- Standby connection
>>PF -- Profile parse failure  PB -- Profile busy
>>RS -- remote site standbySN -- Static Neighbor
>>LB -- Local site not best-site   RB -- Remote site not best-site
>>VM -- VLAN ID mismatch
>> 
>>Legend for interface status
>>Up -- operational
>>Dn -- down
>> 
>>Instance: mihai-vpls
>>   Local site: a (1)
>>No connections found.
>> 
>>x> show route table mihai-vpls.l2vpn.0 detail
>> 
>>mihai-vpls.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown,
>>0 hidden)
>>  10:10:1:1/96 (1 entry, 1 announced)
>> *L2VPN  Preference: 170/-101
>> Next hop type: Indirect
>> Address: 0x26d8270
>> Next-hop reference count: 2
>> Protocol next hop: (null)
>>  

[j-nsp] Static NAT and VPN tunnels

[Aaron Dewell]

Hey all,

Got a conflict here and hoping someone has some ideas on this.  We have 1:1 
static nat for a server, but that server also needs to communicate over a 
policy-based VPN.  If this VPN were route-based, there'd be no problem.  

The VPN works for this server if I remove the static NAT so everything there is 
good.

The option I've considered is to create a static route to the remote subnet 
which goes into a different zone (even a fake zone) and adjust the policies to 
go into that zone instead of the Internet zone.  However, the traffic from the 
far side would still be coming from the Internet zone, so I'm betting the flows 
wouldn't match.  It also seems like an extreme hack.

Removing the static NAT would be awesome, but there are unknown things using 
it, so it's not so easy as that.

Anyone have other suggestions?

Thanks!

Aaron


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] BGP Multipath

[Aaron Dewell]

It depends how careful you want to be about it. Multipath and adding the
peer as you've described will get you half traffic on each immediately
which is fine assuming the circuit is good, etc.

If it were me, I'd probably bring up the new one with a different policy
(same group, policy under the neighbor for now) that assigns all prefixes a
lower localpref  than the default (which is 100) or a higher MED (either
will do the same) except a few test prefixes. Make sure bgp comes up, test
those prefixes for a few days, then remove the temporary policy and remove
the peer over GE and multipath at that point.

Either approach is fine. It depends what you are concerned about and what
you want to protect against.
On Jul 18, 2013 5:14 PM, "Keith"  wrote:

> We recently just turned up another connection to one of our upstreams, so
> now we have two. One is a GE the other is a 10GE.
>
> We are getting into new territory here.
>
> The GE connection is in use and working fine.
>
> These two connections home to two different routers on our upstream.
>
> As the BGP policy will remain the same, I was just going to add a new
> neighbour statement to that
> particular BGP group for that upstream.
>
> I was told to also add multipath to that as well if I want to use both
> connections for load balancing.
>
> Don't really want to use both as the GE will be going away sometime, but
> to make sure it works I was
> going to add the new neighbor IP address, make sure BGP comes up and
> traffic is there then remove the old neighbor
> IP address.
>
> Would this be a sensible way to do it?
>
> Thanks.
> __**_
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/**mailman/listinfo/juniper-nsp
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] j2320 auto power-on

[Aaron Dewell]

Mine do it automatically.  I've never set anything to make them do that.

On Jul 10, 2013, at 9:08 AM, Mark Felder wrote:
> Is there some way to make a j2320 auto power on when power is restored? I 
> can't seem to successfully find this on Google
> ___
> 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] Can I do "dumb" Q-in-Q switching on Juniper MX?

[Aaron Dewell]

You could do this over CCC on an MPLS core for sure (take the whole port not 
logical interfaces).  If your core is q-in-q though, you can configure your 
customer vlans as a range instead of a single number.  That potentially creates 
issues if multiple customers on the same SVLAN are using the same CVLAN id.  
However, if you use a single SVLAN per customer, then there's no issue.

I'd say it's easier to do this using CCC but YMMV.

Aaron

On Jul 1, 2013, at 4:11 AM, Sebastian Wiesinger wrote:
> Hello,
> 
> I need to do a sort of "dumb" Q-in-Q on a MX box. What I want from
> the MX is:
> 
> Take alle VLAN tagged frames on an Port (CE-facing) and switch
> them to another interface (Core-Facing). On the core-facing interface
> push VLAN 42 on the frames (Q-in-Q).
> 
> When frames arrive on the core-facing IF, remove vlan tag 42 and
> switch them to the CE.
> 
> I don't need mac-learning for this as this is just p2p switching.
> 
> (How) is that achievable?
> 
> 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

Re: [j-nsp] IP address

[Aaron Dewell]

There are two usable ips and no broadcast or network address.  One device
can have .0 and the other one .1.
On May 1, 2013 8:56 AM, "Murphy, Jay, DOH"  wrote:

>   10.8.0.1/31 What are the useable IPs. What is the broadcast and network
> address in this subnetwork?
>
> ** **
>
> Thanks.
>
> ** **
>
> Daniel
>
> ** **
>
> ___
> 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] Inserting security policies on SRX

[Aaron Dewell]

Insert doesn't create it, it re-orders existing policies. IMHO it's
confusingly named.

So you create the policy using set (which puts it at the end) then you use
insert to re-order it in the position you want.
On May 1, 2013 8:32 AM, "James S. Smith"  wrote:

> I have an SRX240 running 11.1R2.3, and occasionally I have to add new
> policies.  The obvious choice would seem to be use the insert command but
> I’m getting some weird errors.  For example, I have a number of policies
> for the different protocols going between the IT staff and the untrust
> zone.  When trying to insert a new policy the SRX complains the policy does
> not exist.
>
> ** **
>
> jsmith@fw01# insert security policies from-zone it_staff to-zone untrust
> policy it_staff-untrust-windows-rdp before policy it_staff-untrust-default
> 
>
> error: statement 'it_staff-untrust-windows-rdp' not found
>
> ** **
>
> ** **
>
> ** **
>
> *James S. Smith *Network Architect
>
> *WIND Mobile *207 Queen's Quay West, Suite 710* *Toronto, ON M5J 1A7
>
> ** **
>
> *Email: *jsm...@windmobile.ca**
>
> *Direct:* 416-640-9792
>
> ** **
>
> *Fax: *416-987-1203  
>
> * *
>
>  
> 
> 
>
> 
>
> ___
> 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 - Static Routing Out Same Interface

[Aaron Dewell]

That seems like it should work. Note that you'd need a policy in place
from/to the same zone to allow this traffic.  Even intrazone traffic is
denied by default on an srx.  I suspect that might be the issue here.
On May 1, 2013 8:49 AM, "Bruce Buchanan"  wrote:

>  Hi List –
>
> ** **
>
> Can anyone give any suggestion/guidance on the following.
>
> ** **
>
> I’m trying to do a static route **out** the same interface that the
> traffic came **in** on.  This is on an SRX-240
>
> ** **
>
> Here are the details:
>
> “Private”: 192.168.20.0/24
>
> “Public”: 216.168.x.x/32
>
> Static route: 172.30.200.0/24 to  to
> 192.168.20.121
>
> ** **
>
> 192.168.20.121 is the IP on a VPN appliance.
>
> ** **
>
> Traffic from a client computer never gets routed to the VPN appliance.
> This works on a Cisco 2800 without a problem, but I can’t get it working on
> the SRX.
>
> ** **
>
> Thanks,
>
> Bruce
>
> ** **
>
> *Bruce Buchanan*
> Senior Network Technician
> Nexicom
> 5 King St. E., Millbrook, ON, LOA 1GO
> Phone: 705-932-4147
> FAX: 705-932-3027
> Cell: 705-750-7705
> Web: http://www.nexicom.net
> *Nexicom – Connected. Naturally.*
>
> [image: Click to call 
> me]
> 
>
> ** **
>
> ___
> 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] 3G/4G on SRX

[Aaron Dewell]

I have a cx111 which I use when the primary connection goes down.  I'm
using usb tethering from my phone which works only if you're willing to
constantly mess with it. I wouldn't recommend that setup.

However, I have a customer using the non rebadged cx111 (aka cradlepoint
cba750) with the paired verizon modem attached. There is an always on ipsec
tunnel running over it from the srx. It goes down about an hour a day
average in each site. As long as that doesn't coincide with a t1 outage...
it's all good. Still investigating the reasons for those drops.

So ymmv but it works decently well.

Note that neither of those experiences are with prepaid or m2m. I imagine
it would be the same until you ran out of credit.

Aaron
On May 1, 2013 10:33 PM, "Jeff Rooney"  wrote:

> Does anyone have any experience using a prepaid or month to month 3G/4G
> connection on a branch SRX? I am looking to replace a dial backup with a
> cellular connection, but the documentation is pretty weak and only
> references a Sierra Wireless AirCard.
>
> Any suggestions? Thanks.
>
> Jeff
> ___
> 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] srx240 VPN Question

[Aaron Dewell]

I use this for backup connectivity on dynamic endpoints and they are quite 
happy.  One end must be fixed (which I assume is yours).

Their configuration:

set security ike gateway gateway-name local-identity inet their-vpn-ip-address
set security ike gateway gateway-name remote-identity inet your-vpn-ip-address

Yours:

set security ike gateway gateway-name local-identity inet your-vpn-ip-address
set security ike gateway gateway-name dynamic inet their-vpn-ip-address
delete security ike gateway gateway-name address

I believe this requires 11.3+ but I'm not exactly sure.  The remote-identity 
command is not there in earlier versions.

Aaron

On May 11, 2011, at 8:53 AM, Pappas, AJ wrote:

> I have a srx240.  I have someone who has a vpn with us who wants to change 
> from a static IP address on an ipsec tunnel to a FQDN.  Is there any 
> documentation on how to do this or if it is possible?  He is able to provide 
> the two ip’s to me that it will be coming from.  This is for a failover from 
> them.  Two separate providers / ip’s.
>  
> AJ Pappas   |   Network Administrator 
> 
> Ottawa Regional Hospital & Healthcare Center
> 
> 
> 
> www.ottawaregional.org  |  apap...@ottawaregional.org 
> phone: 815.431.5180 | mobile line: 815.993.8522 
> 1100 East Norris Drive, Ottawa, IL 61350 USA
>  
> P  Please consider the environment before printing this e-mail.
>  
>  
> Confidentiality Notice: This e-mail may contain confidential information.  
> The information is intended only for the use of the recipient named above.  
> If you are not the intended recipient, you are hereby notified that any 
> disclosure, copying, distribution, or the taking of any action in reliance on 
> the contents of this information, except its direct delivery to the intended 
> recipient named above, is strictly prohibited.  If you have received this 
> e-mail in error, please notify the sender of this and also delete the e-mail 
> from all systems this message is stored on.
>  
> ___
> 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] ike túnnel termination on 5800s

[Aaron Dewell]

A reth interface is essentially an aggregated ethernet interface except only 
half are active at any one time.  So the difference is (almost, practically) 
zero.

As to loopback termination, I've not actually tried it.  I believe (without 
trying or any actual data) that it requires the actual physical outbound 
interface (or reth).

Aaron

On Apr 3, 2013, at 2:12 PM, OBrien, Will wrote:
> Hey guys, I'm building a new cluster of SRX 5800s and prepping to move 
> several VPN tunnels to it. All of them are ike/ipsec.
> 
> I built a test site on a SRX210 and configured a tunnel between it and my 
> cluster. My tunnels aren't coming up on the 5800 side at all.
> I'm using Agg Eth interfaces on each chassis cluster member since they are in 
> diverse locations and the ciscos they connect to aren't configured for VPC 
> pairing.
> 
> Basically, I've got a 20Gb Agg link up and down from each cluster member. Up 
> heads to my DMZ/Internet and Down goes to the client core. (and a 20Gb lane 
> between the cluster members)
> 
> In checking my documentation on VPN tunnels, I found this gem:
> http://kb.juniper.net/InfoCenter/index?page=content&id=KB19829&actp=search&viewlocale=en_US&searchid=1365002153257
> 
> Apparently, high end SRX isn't supporting IKE unless it's via a RETH 
> interface.  WHAT THE FREAKING HELL
> 
> So, after some work with JTAC to validate my working plan, we configured our 
> agg links as reth interfaces, which have two members off the same chassis to 
> work around the restriction.
> 
> I now have tunnels talking to my new "reth" interfaces, but I'm incredibly 
> displeased that I can't just terminate those on a loopback.
> 
> 
> Are there any angles I'm missing on this? I can mostly live with the altered 
> configuration. Luckily I planned to transition my vpn tunnels first, so I was 
> able to reconfigure my DMZ uplinks without incurring an outage.
> 
> 
> 
> ___
> 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] Clustering J-series across a switch

[Aaron Dewell]

IIRC, it's possible but not recommended due to the reliability issue of the 
switch in between.  In your situation, I'd probably give it a shot.

Definitely use different VLANs for control and fabric.

Aaron

On Apr 2, 2013, at 10:47 AM, Mike Williams wrote:
> Hey all,
> 
> So I've been reading the clustering docs, and they make it pretty clear that 
> the (at least) control link should connect the devices "back-to-back".
> I don't have the page to hand but there is an option to configure the control 
> link in the old way, using (a?) VLAN (4094 IIRC), otherwise new clusters will 
> use a special ether-type.
> 
> Now if Junos is going to use a new ether-type for control link communication 
> it's pretty certain the devices would have to be connected "back-to-back", 
> but 
> if control link traffic is within a specific VLAN switching it shouldn't be a 
> problem, right? I'd q-in-q the traffic anyway.
> 
> The health of the control and fabric links is determined by heartbeats only, 
> not link state, so a switch wouldn't hurt that.
> 
> I accept that clustering across a switch isn't necessarily advisable, I'm 
> just 
> wondering if it's fundamentally possible.
> Has anyone ever even tried to put a switch between a J-series, or SRX-series, 
> cluster?
> 
> Thanks
> 
> 
> Currently we've 2 J6350s on different floors of a building, with different 
> providers. Around that building we have a 10Gbps VC ring of EX3300s. We want 
> to cluster the J-series' but don't want the hassle or cost of running copper 
> between the providers (if that's even possible) when the VC is way more than 
> fast enough.
> Traffic levels are way way below 10Gbps, and it's highly unlikely they'll 
> ever 
> get that high.
> 
> -- 
> Mike Williams
> ___
> 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] Help needed with IPSEC VPN on J-Series

[Aaron Dewell]

You'll also need a policy which allows traffic from trust to trust, i.e.:

set security policies from-zone trust to-zone trust match source-address any
set security policies from-zone trust to-zone trust match destination-address 
any
set security policies from-zone trust to-zone trust match protocol any
set security policies from-zone trust to-zone trust then permit

Cross-interface traffic is not allowed by default even within the same zone.

On Mar 20, 2013, at 10:16 AM, Bill Sandiford wrote:
> For the most part this J-series has always just acted as a router without
> any tunnels per se.  As such, I have always had all interfaces in the
> trust zone, as follows
> 
> zones {
>security-zone trust {
>tcp-rst;
>host-inbound-traffic {
>system-services {
>any-service;
>}
>protocols {
>all;
>}
>}
>interfaces {
>all;
>}
>}
> }
> 
> Will this accomplish what you are suggesting?
> 
> 
> 
> 
> 
> 
> 
> On 2013-03-20 11:52 AM, "Patrick Dickey"  wrote:
> 
>> I don't remember if the J series behaves exactly like the SRXs when it
>> comes
>> to IPSec, but if it is make sure to put the st0.x interface into a
>> security
>> zone and have a security policy allowing the traffic.
>> 
>> I believe that's only a requirement if you're running the enhanced
>> services/security code on the J, but I think you have to be to get IPSec.
>> 
>> HTH
>> 
>> 
>> -Original Message-
>> From: juniper-nsp-boun...@puck.nether.net
>> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Bill Sandiford
>> Sent: Wednesday, March 20, 2013 8:47 AM
>> To: juniper-nsp@puck.nether.net
>> Subject: [j-nsp] Help needed with IPSEC VPN on J-Series
>> 
>> Hi All,
>> 
>> I need some help with an IPSEC tunnel that I just can't seem to get
>> working
>> on a J-6350.  I have been able to get the tunnels to come up, but can't
>> seem
>> to pass traffic over the tunnels
>> 
>> I've done the usual things.  I've created an st0.0 interface and bound it
>> to
>> the tunnel using the bind-interface command.  I've created a static route
>> and pointed it at the st0.0 interface.  I just can't seem to get traffic
>> to
>> pass over the tunnel.
>> 
>> Any help or suggestions would be appreciated.  I'm also willing to put a
>> $$$
>> bounty on this for anyone that is willing to help me get it working via
>> teamviewer.
>> 
>> Regards,
>> Bill
>> 
>> 
>> ___
>> 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] SRX with CX111 int to vlan

[Aaron Dewell]

On Mar 12, 2013, at 7:44 PM, Aaron Dewell wrote:
> 
> Quick question for you all (I'm sure I'm doing something dumb here).
> 
> I had this working config:
> […]
> 
> 
> That was working.  Now I want to be able to get to the CX111's management 
> VLAN, so I changed it to this:
> 
> […]
> 
> And yes, I just wrote that out. :-)  So if it's less than perfect syntax, 
> that's why.  Anyway, you get the idea.  vlan.3900 will be in a zone, but my 
> immediate concern is no longer getting a DHCP address from the CX111 (this 
> time on vlan.10 instead of ge-0/0/0.0).
> 
> Does anyone see anything quick that I did wrong here?
> 
> Thanks!
> 
> Aaron

Replying to myself, here's the exact show | compare:

[edit interfaces ge-0/0/0 unit 0]
-  family inet {
-  dhcp;
-  }
+  family ethernet-switching {
+  port-mode trunk;
+  vlan {
+  members cx111-mgmt;
+  }
+  native-vlan-id cx111-internet;
+  }
[edit interfaces vlan]
+unit 10 {
+description "CX111 Backup internet for IPSec Tunnel";
+family inet {
+dhcp;
+}
+}
+unit 3900 {
+description "CX111 management VLAN";
+family inet {
+address 192.168.0.2/24;
+}
+}  
[edit security ike gateway Backup]
-external-interface ge-0/0/0.0;
+external-interface vlan.10;
[edit security zones security-zone Untrust interfaces]
+ vlan.10 {
+ host-inbound-traffic {
+ system-services {
+ ping;
+ ike;
+ dhcp;
+ }
+ }
+ }
- ge-0/0/0.0 {
- host-inbound-traffic {
- system-services { 
- ping;
- ike;
- dhcp;
- }
- }
- }
[edit routing-instances ISP]
-interface ge-0/0/0.0;
+interface vlan.10;
[edit vlans]
+   cx111-internet {
+   vlan-id 10;
+   l3-interface vlan.10;
+   }
+   cx111-mgmt {
+   vlan-id 3900;
+   l3-interface vlan.3900;
+   }


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] SRX with CX111 int to vlan

[Aaron Dewell]

Quick question for you all (I'm sure I'm doing something dumb here).

I had this working config:

routing-instances {
ISP {
instance-type virtual-router;
interface ge-0/0/0.0;
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
dhcp;
}
}
}
}
security {
zones {
security-zone Untrust {
interfaces {
ge-0/0/0.0 {
host-inbound-traffic {
dhcp;
ping;
ike;
}
}
}
}
}
}



That was working.  Now I want to be able to get to the CX111's management VLAN, 
so I changed it to this:

routing-instances {
ISP {
instance-type virtual-router;
interface vlan.10;
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members cx111-mgmt;
}
native-vlan-id cx111-internet;
}
}
}
vlan {
unit 10 {
family inet {
dhcp;
}
}
unit 3900 {
family inet {
address 192.168.0.2/24;
}
}
}
}
security {
zones {
security-zone Untrust {
interfaces {
vlan.10 {
host-inbound-traffic {
dhcp;
ping;
ike;
}
}
}
}
}
}
vlans {
cx111-internet {
vlan-id 10;
l3-interface vlan.10;
}
cx111-mgmt {
vlan-id 3900;
l3-interface vlan.3900;
}
}


And yes, I just wrote that out. :-)  So if it's less than perfect syntax, 
that's why.  Anyway, you get the idea.  vlan.3900 will be in a zone, but my 
immediate concern is no longer getting a DHCP address from the CX111 (this time 
on vlan.10 instead of ge-0/0/0.0).

Does anyone see anything quick that I did wrong here?

Thanks!

Aaron
___
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?

[Aaron Dewell]

I tried ISSU twice, both times on 3 MX routers during a single maintenance 
window, going from 10.x to 11.x.  It failed spectacularly on the second router, 
requiring manual recovery via the console (mastership was not assumed by the 
backup before the primary rebooted), so I completely gave up on the procedure 
and did the rest of the 50+ routers in the network the old-fashioned way, one 
RE at a time, with a 2 minute hit for switchover in the middle.

After that, I don't recommend ISSU to anyone.  It's not worth the hassle, at 
least not yet.  Maybe about 14.x it will be stable enough to use.

On Mar 8, 2013, at 11:10 AM, Tim Eberhard wrote:
> 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=content&id=KB17946&actp=RSS
> 
> 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
>  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=content&id=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


___
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?

[Aaron Dewell]

Not that I've had to do it - but I'd probably break the cluster to do the 
upgrade and run on one during the procedure.  

On Mar 8, 2013, at 10:50 AM, Andy Litzinger 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=content&id=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] VirtualBox arp problem

[Aaron Dewell]

Hello all,

I thought maybe more than a few might have used VB before and might know the 
answer to this.  In my lab, I have this setup:

SRX100 cluster  EX2200-C  Mac Mini host running Lion and VB  VMs

I'm trying to do BGP from the cluster to the VMs, but the current step is just 
ping.  I have assigned IP addresses to all devices temporarily to facilitate 
testing, the ultimate goal is L2 across to the VMs.  

The problem appears to be ARP replies not reaching the VM.

If anyone has any ideas, I'd definitely appreciate it!

Thanks!

Aaron




IP addresses are:

Cluster:172.32.2.40/24
EX: 172.32.2.30/24
Mini:   172.32.2.1/24
VM: 172.32.2.50/24

The VM can ping the Mini, the Mini can ping everything, the EX and Cluster can 
ping everything except the VM.  I do get ARP replies (and shows the MAC 
addresses are not shared with the host) on the cluster, but not on the VM (VM 
only receives ARP entries for the Mini).  The Mini receives ARP entries for all 
other devices (as expected).  The ethernet-switching table on the EX contains 
all devices:

acd@crossroads> show ethernet-switching table vlan lab-internet2
Ethernet-switching table: 3 unicast entries
  VLAN  MAC address   Type Age Interfaces
  lab-internet2 * Flood  - All-members
  lab-internet2 08:00:27:f2:bc:5e Learn   2:25 ge-0/0/10.0  
VM
  lab-internet2 3c:07:54:56:8c:61 Learn  0 ge-0/0/10.0  
Mini
  lab-internet2 88:e0:f3:68:78:41 Static - Router
  lab-internet2 ac:4b:c8:cd:3c:40 Learn   2:38 ge-0/0/9.0   
SRX


The NIC in question from "VBoxManage showvminfo":
NIC 3:   MAC: 080027F2BC5E, Attachment: Bridged Interface 'vlan1', 
Cable connected: on, Trace: off (file: none), Type: 82540EM, Reported speed: 0 
Mbps, Boot priority: 0, Promisc Policy: allow-all, Bandwidth group: none

In the Mac settings, I have it configured as a trunked interface (virtual 
interface - VLAN) where it is configured (IPv4) manually with the IP address 
and no router:

vlan1: flags=8943 mtu 1500
options=23
ether 3c:07:54:56:8c:61 
inet6 fe80::3e07:54ff:fe56:8c61%vlan1 prefixlen 64 scopeid 0x9 
inet 172.32.2.1 netmask 0xff00 broadcast 172.32.2.255
vlan: 501 parent interface: en0
media: autoselect (1000baseT )
status: active

And IPv4 forwarding is enabled:

% sysctl -a | grep forward
net.inet.ip.forwarding: 1
net.inet6.ip6.forwarding: 0


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Weird ARP issue

[Aaron Dewell]

Sounds like a Xen bridge issue, but I have no definitive experience or reason 
other than that's the only thing in the path which might block it.  Strange 
that it would pass an arp for a ping but not for SSH.  Should be the same arp 
off the switch either way.

On Jan 30, 2013, at 5:41 PM, Luca Salvatore wrote:
> I have a very strange problem that may or may not be related to my switch, 
> but I'm running out of ideas.
> 
> 
> I have a EX4200 switch running 11.4R2.14.  The EX has a bunch of VLANs and is 
> doing some basic routing using the L3 VLAN interfaces.
> Connected to this switch is some servers running XenServer with a bunch of 
> VMs.
> 
> Now, the issue I'm seeing is:
> When I try to SSH to a VM running on the XenServers i don't get any 
> connection.
> If I then send a ping to the VM my SSH connection works.
> 
> What I see happening is that there is no ARP entry in the switch when I use 
> SSH.
> As soon as I send a ping, the switch sends an ARP request and gets a reply.
> 
> In other words:
> When SSH is used and I do a TCP dump on the server I do not see an ARP request
> But when I send a ping, I see the ARP request (from the switch) hit the 
> server and the response comes back, the switch the has an ARP entry and 
> everything works.
> 
> Wondering if anyone has any thoughts here?
> I'm about to do a port-mirror to try and dig a bit deeper, but not really 
> confident it will help.
> 
> Thanks
> Luca.
> 
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Splitting Dot1q VLAN across Logical Systems

[Aaron Dewell]

Not true. Logical interfaces are allocated to logical systems, not physical
interfaces. No problem with what you're doing.
On Jan 24, 2013 4:28 AM, "Skeeve Stevens" 
wrote:

> Hey all,
>
> I want to build this scenario.
>
> 2 * MX80, with a trunk between then.
>
> On the trunk (as an example) there would be two VLANs.
>
> I would like to take VLAN 100 on Router-A Logical System A to Router-B
> Logical System A, while at the same taking VLAN 200 on Router-A Logical
> System B to Router-B Logical System B.
>
> Does this make sense?
>
> I'm hearing I have to allocate a whole physical interface to a Logical
> System which means I can't use a VLAN from it for another Logical System.
>
> Does this make sense with what I am looking to do?
>
> Thanks ;-)
> *
>
> *
> *Skeeve Stevens, CEO - *eintellego Pty Ltd
> ske...@eintellego.net ; www.eintellego.net
>
> Phone: 1300 753 383; Cell +61 (0)414 753 383 ; skype://skeeve
>
> facebook.com/eintellego ;  
> linkedin.com/in/skeeve
>
> twitter.com/networkceoau ; blog: www.network-ceo.net
>
> The Experts Who The Experts Call
> Juniper - Cisco – IBM - Brocade - Cloud
> -
> Check out our Juniper promotion website!  eintellego.mx
> ___
> 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 and not working VRRP

[Aaron Dewell]

Actually, you have to do that on an MX also.  By default, the virtual IP will 
not accept anything destined for it (such as pings) unless you enable 
accept-data.  The "real" IP of the interface will respond, but not the shared 
address.

Now, I have seen hokey setups before where people had configured a "real" IP as 
the virtual.  it worked (though I wouldn't guarantee failover results) and it 
would respond to ping in that case (since it was a "real" IP).  To do it 
properly, it needs 3 IP addresses (1 for primary, 1 for secondary and one 
shared).

What's different on the SRX is that the protocol has to be enabled in the 
zone/interface.

Aaron

On Jan 8, 2013, at 5:16 PM, Robert Hass wrote:
> On Wed, Jan 9, 2013 at 12:40 AM, Chuck Anderson  wrote:
>> set vrrp-group 0 accept-data
> 
> Thanks a lot !. It helped.
> 
> I used VRRP earlier on MX where this is not necessary to make VRRP
> work (but 10.4 on MX).
> Is above command is SRX (JunOS-ES) specific ?
> 
> Rob
> ___
> 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-SRX IPSec multipoint with dynamic endpoints fails with new IP

[Aaron Dewell]

Hello all,

So I have this hub-and-spoke multipoint VPN on various SRX240 firewalls.  It's 
working generally, the problem is with the dynamic endpoints.  When they shift 
IP addresses, the hub won't allow them to connect anymore because of the old 
state from the prior IP address.

Is this something that DPD (which is not configured) would solve?  Is the 
another solution that would be better?

Below is the hub site configuration.  The spokes look similar (except address 
instead of dynamic defining the hub's fixed IP and different 
external-interface).  The hub is a cluster if that makes a difference.

Thanks for any insight!

Aaron


ike {
policy remotes {
mode aggressive;
proposal-set standard;
pre-shared-key ascii-text bla;
}
gateway SITEX {
   ike-policy remotes;
dynamic inet WAN-SITEX-IP;
local-identity inet WAN-LOCAL-IP;
external-interface reth2.0;
}
}
ipsec {
policy remotes {
perfect-forward-secrecy {
keys group2;
}
proposal-set standard;
}
vpn SITEX {
bind-interface st0.0;
ike {
gateway SITEX;
ipsec-policy remotes;
}
}
}

st0 {
unit 0 {
multipoint;
family inet {
address WAN-LOCAL-IP/22;
}
}


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] DHCP interface as next hop

[Aaron Dewell]

On Nov 29, 2012, at 12:53 AM, Tore Anderson wrote:
> * Aaron Dewell
> 
>> I haven't found an answer to this question (except for Cisco options
>> which doesn't help me).  I want to configure a static route to a DHCP
>> interface on an SRX240.  Here's the scenario:
>> 
>> ge-0/0/0 connected to CX111 (4G modem/DHCP)
>> t1-0/1/0 connected to an L3VPN (with BGP)
>> st0.0 should connect over ge-0/0/0
>> 
>> The t1 is considered trusted, so we do not want to form the IPSec
>> tunnel over it.  There is a default route coming in via BGP on the
>> T1.  The goal:
>> 
>> Statically route the IPSec tunnel endpoint over the 4G modem as a
>> /32
>> Statically route 0/0 over st0.0 (and set precedence to >170, or set
>> BGP down to 4)
>> Receive 0/0 from BGP over the T1 (or alternately not, with no need to
>> alter precedence, and use two next-hops for one static 0/0)
>> 
>> The purpose is to have the tunnel up but not used until the T1 or BGP
>> over it goes away.
>> 
>> However, I cannot set ge-0/0/0.0 as the next-hop because it's not a
>> point to point interface. I cannot set an IP address as the next-hop
>> because I don't know when it will change.
>> 
>> Any ideas on how to address that?
> 
> I have no idea if this can be done or will work, but here's a suggestion
> at least:
> 
> Configure a static link network (e.g., 192.0.2.10/31) on ge-0/0/0.0
> in parallel with the DHCP client. Add a static ARP entry for 192.0.2.11
> pointing to the CX111's MAC address. Use 192.0.2.11 address as the next
> hop for the static route to the remote IPSEC tunnel endpoint.
> 
> Best regards,
> -- 
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com/

Ooooh, I like that idea.  I'll give that a try.  The other idea our SE 
suggested is a virtual router and configure the static route with next-table.  
But that requires 12.1R3 to fix the default route installed into inet.0 not the 
VR issue.  I like your idea more than upgrades+VRs.

Aaron



___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] DHCP interface as next hop

[Aaron Dewell]

Hey all,

I haven't found an answer to this question (except for Cisco options which 
doesn't help me).  I want to configure a static route to a DHCP interface on an 
SRX240.  Here's the scenario:

ge-0/0/0 connected to CX111 (4G modem/DHCP)
t1-0/1/0 connected to an L3VPN (with BGP)
st0.0 should connect over ge-0/0/0

The t1 is considered trusted, so we do not want to form the IPSec tunnel over 
it.  There is a default route coming in via BGP on the T1.  The goal:

Statically route the IPSec tunnel endpoint over the 4G modem as a /32
Statically route 0/0 over st0.0 (and set precedence to >170, or set BGP down to 
4)
Receive 0/0 from BGP over the T1 (or alternately not, with no need to alter 
precedence, and use two next-hops for one static 0/0)

The purpose is to have the tunnel up but not used until the T1 or BGP over it 
goes away.  

However, I cannot set ge-0/0/0.0 as the next-hop because it's not a point to 
point interface. I cannot set an IP address as the next-hop because I don't 
know when it will change.  

Any ideas on how to address that?

Thanks!

Aaron
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] OSPF next hop

[Aaron Dewell]

On Jul 24, 2012, at 2:04 PM, Wayne Tucker wrote:
> On Tue, Jul 24, 2012 at 12:36 PM, Aaron Dewell  wrote:
>> Yes, Type Transit (2).  However, the Network LSA only includes 3 attached 
>> routers (should be 6 currently).  There are two Network LSAs in R7.  One has 
>> the interface IP of R1 (non-DR/BDR) with 3 attached routers (R1, R5, R6).  
>> The other has the interface IP of R2 and shows 3 attached routers (R2, R7, 
>> and R8).  The interfaces on R3 and R4 are currently shut down.
>> 
>> Further looking into it, there is disagreement all across this network about 
>> who is the DR and BDR.  Half the routers show one set, and half show the 
>> other.  I think that might produce some issues!
> 
> Wow, that is weird.  If L2 communication is good across the segment
> then MTU or authentication mismatch would be my next guess.
> 
> It might be worth turning on OSPF tracing, if you haven't done so already:
> 
> set protocols ospf traceoptions file ospf-trace.log size 2m files 2
> world-readable
> set protocols ospf traceoptions flag error detail
> 
> There are other flags available, but I've found that "error detail"
> almost always provides me the information I need.  At the same time,
> it's pretty quiet under normal conditions (so I leave it enabled on
> most of my OSPF routers).
> 
> :w

This is a shared segment across a layer 2 provider, and at this point, we think 
it's partial connectivity across them.  I think the routers are behaving 
properly given a semi-random connectivity on this supposed broadcast segment.

The initial symptom just threw me.  :-)  

Aaron


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] OSPF next hop

[Aaron Dewell]

On Jul 24, 2012, at 4:56 AM, Wayne Tucker wrote:

> On Mon, Jul 23, 2012 at 11:02 PM, Aaron Dewell  wrote:
>> I ran into an odd behavior here tonight, I'm hoping someone has some ideas.  
>> We have 8 routers on a broadcast OSPF segment.  All are advertising their 
>> loopback addresses (amongst other things).  I'll call this R1 to R8 for now. 
>>  Their IP addresses on this shared segment are 192.168.0.16X/28 (X 
>> corresponding to RX).
>> 
>> R2 is the current DR and R6 is the BDR.  All the priorities are the same, 
>> not that it matters.
>> 
>> From R7, all routes to the other routers' loopback address cross R2!  I'm 
>> not sure if it's because it happens to be the DR or what.
>> 
>> acd@R7> show route 
>> 
>> inet.0:  destinations,  routes ( active, 0 holddown, 4 hidden)
>> + = Active Route, - = Last Active, * = Both
>> 
>> /32  *[OSPF/10] 23:57:02, metric 40045
>>> to 192.168.0.162 via ge-0/0/3.200
>> 
>> The metric indicates that the path is: R7->R2->R1->R6, which is proven by 
>> the traceroute.  The metric for this broadcast segment is 2 on all 
>> routers.  The 45 is a 10G interface directly connecting R2 and R1.  The 
>> metric of the correct path is exactly 20k (directly connected over this 
>> shared segment).
>> 
>> The example is typical, all of the other router's loopback's look the same 
>> (except R8 which is it's buddy and directly connected).
>> 
>> Any ideas on what else to look at?  The OSPF database looks reasonable.  Our 
>> other shared segments act normal.  All routers are on 11.4R2.
> 
> That is odd.  Do all of the routers have a full adjacency with the DR and BDR?
> 
> Does each router LSA show a transit link to the ID if the type 2 LSA
> for that network (it should show that address in the "data" field)?
> 
> :w

Yes, Type Transit (2).  However, the Network LSA only includes 3 attached 
routers (should be 6 currently).  There are two Network LSAs in R7.  One has 
the interface IP of R1 (non-DR/BDR) with 3 attached routers (R1, R5, R6).  The 
other has the interface IP of R2 and shows 3 attached routers (R2, R7, and R8). 
 The interfaces on R3 and R4 are currently shut down.

Further looking into it, there is disagreement all across this network about 
who is the DR and BDR.  Half the routers show one set, and half show the other. 
 I think that might produce some issues!

Aaron


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] OSPF next hop

[Aaron Dewell]

Hi all,

I ran into an odd behavior here tonight, I'm hoping someone has some ideas.  We 
have 8 routers on a broadcast OSPF segment.  All are advertising their loopback 
addresses (amongst other things).  I'll call this R1 to R8 for now.  Their IP 
addresses on this shared segment are 192.168.0.16X/28 (X corresponding to RX).  

R2 is the current DR and R6 is the BDR.  All the priorities are the same, not 
that it matters.

>From R7, all routes to the other routers' loopback address cross R2!  I'm not 
>sure if it's because it happens to be the DR or what.

acd@R7> show route 

inet.0:  destinations,  routes ( active, 0 holddown, 4 hidden)
+ = Active Route, - = Last Active, * = Both

/32  *[OSPF/10] 23:57:02, metric 40045
> to 192.168.0.162 via ge-0/0/3.200

The metric indicates that the path is: R7->R2->R1->R6, which is proven by the 
traceroute.  The metric for this broadcast segment is 2 on all routers.  
The 45 is a 10G interface directly connecting R2 and R1.  The metric of the 
correct path is exactly 20k (directly connected over this shared segment).

The example is typical, all of the other router's loopback's look the same 
(except R8 which is it's buddy and directly connected).

Any ideas on what else to look at?  The OSPF database looks reasonable.  Our 
other shared segments act normal.  All routers are on 11.4R2.

Thanks!

Aaron


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Split VRF traffic

[Aaron Dewell]

Hi all,

Quick question for you all.  Is it possible to define static routes within a 
VRF on a PE router that specify different P routers as next-hops?  These are 
2547 VPNs, BGP signaled etc.

The first hop signaling is LDP, thereafter enters an RSVP LSP.  

Quick and dirty diagram:

1.1.1.1  PE1 --- P1 --\   /-- PE3  3.3.3.3
   X|   |Network   |   X
2.2.2.2  PE2 --- P2 --/   \-- PE4  4.4.4.4

The hops that need to be protected are PE1-P1 and PE2-P2.  The requirement is 
that we split half of critical traffic across each link.  Static routing is 
fine, and failover is unimportant.  

1.1.1.1 talks to 3.3.3.3 and 4.4.4.4, 2.2.2.2 talks to both as well.  The path 
1.1.1.1 to 3.3.3.3 should cross PE1-P1, while 1.1.1.1 to 4.4.4.4 should cross 
PE2-P2 (and the reciprocal situation for 2.2.2.2).

iBGP sessions are between PE1 to P1 (loopback to loopback which consider each 
other RR clients), PE1 and PE2, and P1 and P2 participate in the backbone full 
mesh.  There is no session between PE2 and P2, and I prefer not to add one if I 
don't have to.  However, that is the backup plan.

I'd happily just define static routes for this and move on, but the challenge 
that I've not come up with an answer for yet is that the routes to be split are 
within the VRF, yet the next-hop is in inet.0.  

Any ideas?  Thanks for your input!

Aaron


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Branch SRX and satellite

[Aaron Dewell]

That would explain the slowness in obtaining a lease, but after it's obtained 
it would only be a problem at expiration time, correct?  I haven't observed the 
issue corresponding to expiration.  The lease is obtained (show system services 
dhcp client) and the route installed in both the routing table and forwarding 
table, so I assume that means that (eventually) the DHCP transaction is 
complete.  Just no pings or anything after that.

Aaron

On May 28, 2012, at 4:49 PM, Tim Eberhard wrote:
> What you're most likely running into is the DHCP ttl limitation.
> 
> While it's not often a problem, the SRX sends out a DHCP request with
> a TTL of 1.
> 
> http://forums.juniper.net/t5/SRX-Services-Gateway/SRX-DHCP-client-sends-discover-request-with-TTL-1/td-p/99180
> 
> I've seen this in the past, and while rare it does happen every now
> and again depending on the ISP. As far as I know there hasn't been an
> feature to tweak the TTL for dhcp discover requests.
> 
> I hope this helps,
> -Tim Eberhard
> 
> On Mon, May 28, 2012 at 5:29 PM, Aaron Dewell  wrote:
>> 
>> Hi all,
>> 
>> I've been having a problem with an SRX210 connected to a Wildblue satellite 
>> modem (Surfbeam 2 if it matters).  This is DHCP which appears to be proxied 
>> by the modem.  There are a couple of different states, but neither work:
>> 
>> Case 1: No ARP entry for the DHCP default route (forwarding table entry says 
>> "hold")
>> Case 2: ARP entry but cannot ping the router or anything else
>> 
>> Upon reboot, it works right after obtaining the lease for about 10 seconds, 
>> then stops (in one of those two states).
>> 
>> Their "troubleshooting" method involves plugging it into a PC, which works, 
>> at which point they wash their hands of it, saying it's clearly a router 
>> problem.  I have swapped in an SRX100, as well as another 210, and both 
>> exhibit identical symptoms.  Also, the router works connected to a CX111/VZW 
>> Aircard.  And it has been working for a few months and only quit last week 
>> (no change in SRX config).
>> 
>> The current best theory is an invalid ARP packet which windows accepts but 
>> JunOS does not.  That explains case #1 but not #2.
>> 
>> I have the Wildblue people going out to swap out the modem tomorrow morning 
>> (too bad they can't just send one to switch) on the theory that it's the 
>> most likely thing to be the problem.
>> 
>> Has anyone had any issues with an SRX connected to a  satellite modem 
>> before?  Any suggestions would be greatly appreciated!
>> 
>> Thanks!
>> 
>> Aaron
>> 
>> 
>> ___
>> 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] Branch SRX and satellite

[Aaron Dewell]

Hi all,

I've been having a problem with an SRX210 connected to a Wildblue satellite 
modem (Surfbeam 2 if it matters).  This is DHCP which appears to be proxied by 
the modem.  There are a couple of different states, but neither work:

Case 1: No ARP entry for the DHCP default route (forwarding table entry says 
"hold")
Case 2: ARP entry but cannot ping the router or anything else

Upon reboot, it works right after obtaining the lease for about 10 seconds, 
then stops (in one of those two states).

Their "troubleshooting" method involves plugging it into a PC, which works, at 
which point they wash their hands of it, saying it's clearly a router problem.  
I have swapped in an SRX100, as well as another 210, and both exhibit identical 
symptoms.  Also, the router works connected to a CX111/VZW Aircard.  And it has 
been working for a few months and only quit last week (no change in SRX config).

The current best theory is an invalid ARP packet which windows accepts but 
JunOS does not.  That explains case #1 but not #2.

I have the Wildblue people going out to swap out the modem tomorrow morning 
(too bad they can't just send one to switch) on the theory that it's the most 
likely thing to be the problem.

Has anyone had any issues with an SRX connected to a  satellite modem before?  
Any suggestions would be greatly appreciated!  

Thanks!

Aaron


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] problems with srx240

[Aaron Dewell]

I have observed this on both an srx240 and srx210h. Jtac advised turning
off utm and idp (on 210), yet those were enabled before with no issues. The
240 was fresh out of the box getting initial config (IP, Nat, zones,
policies, I.e. nothing amazing).

I'll be waiting to see the answers too!
On May 5, 2012 7:56 AM, "Maciej Jan Broniarz"  wrote:

> Hi,
>
> My SRX240 box started showing the following error in the logs:
>
> May  5 00:36:08  srx240-lab srx240-lab Frame 00: sp = 0x49202a58, pc =
> 0x08020254
> May  5 00:36:08  srx240-lab srx240-lab Frame 01: sp = 0x49202b00, pc =
> 0x0800c1fc
> May  5 00:36:08  srx240-lab srx240-lab Frame 02: sp = 0x49202b70, pc =
> 0x0800d300
> May  5 00:36:08  srx240-lab srx240-lab Frame 03: sp = 0x49202b90, pc =
> 0x082cb550
> May  5 00:36:08  srx240-lab srx240-lab Frame 04: sp = 0x49202be8, pc =
> 0x080198c0
> May  5 00:36:08  srx240-lab srx240-lab Frame 05: sp = 0x49202c10, pc =
> 0x080198c0
> May  5 00:36:08  srx240-lab srx240-lab Frame 06: sp = 0x49202c38, pc =
> 0x080198c0
> May  5 00:36:08  srx240-lab srx240-lab Frame 07: sp = 0x49202c60, pc =
> 0x08019a2c
> May  5 00:36:08  srx240-lab srx240-lab Frame 08: sp = 0x49202c98, pc =
> 0x0801fc34
> May  5 00:36:08  srx240-lab srx240-lab Frame 09: sp = 0x49202cc0, pc =
> 0x09dc54c8
> May  5 00:36:18  srx240-lab srx240-lab SCHED: Thread 14 (Forwarding
> Thread) ran for 1572 ms without yielding
> May  5 00:36:18  srx240-lab srx240-lab Scheduler Oinker
> May  5 00:36:18  srx240-lab srx240-lab Frame 00: sp = 0x491b8c68, pc =
> 0x08020254
> May  5 00:36:18  srx240-lab srx240-lab Frame 01: sp = 0x491b8d10, pc =
> 0x0800c1fc
> May  5 00:36:18  srx240-lab srx240-lab Frame 02: sp = 0x491b8d80, pc =
> 0x088b3c8c
> May  5 00:36:18  srx240-lab srx240-lab Frame 03: sp = 0x491b8dd0, pc =
> 0x088b76d0
> May  5 00:36:18  srx240-lab srx240-lab Frame 04: sp = 0x491b8e50, pc =
> 0x0801fc34
> May  5 00:36:18  srx240-lab srx240-lab Frame 05: sp = 0x491b8e78, pc =
> 0x09dc54c8
>
> The box isn't heavy loaded - just about 1-2megs of trafiic per sec.
>
> What might be the problem here?
>
> All best,
> mjb
>
> ___
> 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] VPLS Frustrations (Juniper - Cisco)

[Aaron Dewell]

For the flexibility of however they want to do it, I'd suggest CCC and just 
take the whole port over the network.  There are two disadvantages to that plan 
however.  One is that it's point to point only, the second is that it's not 
supported on Cisco.  

L2vpn (kompella) with encapsulation CCC might solve the problem as well.  

CCC is the old-school Juniper way of doing this pre-l2circuit/l2vpn/vpls.  

Aaron

On Mar 27, 2012, at 8:57 AM, Humair Ali wrote:
> Hi Ben
> 
> not sure if you raised it before, but if you are looking at QinQ, and
> point-to-point is a viable solution, you should be able to do QinQ accross
> L2circuit .
> 
> In regards to the Switched network between PE & CE , why not use CFM to
> monitor the service end to end.
> 
> but if you are planning to add more site , then it might become cumbersome
> though
> 
> Regards
> 
> On 27 March 2012 15:33, Ben Boyd  wrote:
> 
>> The CE's can tag or not tag, they want freedom to do whatever they wish.
>> 
>> There is no BGP.  It's all LDP signaled.  That's why an L2VPN isn't
>> possible and VPLS is our only way.
>> you hve a swtiched network
>> 
>> I'm trying to accomplish Q-in-Q or more exactly "possiblyQ-in-Q".
>> 
>> JTAC thinks this is a bug as the Juniper is sending STP traffic and
>> tagging correctly, but it isn't decapsulating the STP traffic coming back.
>> 
>> 
>> 
>> ---
>> Ben Boyd
>> b...@sinatranetwork.com
>> http://about.me/benboyd
>> 
>> 
>> 
>> 
>> On Mar 22, 2012, at 4:48 PM, Keegan Holley wrote:
>> 
>>> Try changing your encapsulation to flexible ethernet services.  It's
>> been a while since I set this up from scratch, but I've never seen a vpls
>> neighbor defined only site-id's and site ranges.  That may not be your
>> problem though.  Are your CE's tagging?  encap vpls only supports untagged
>> packets from the CE.  vlan-vpls or flexible is required to pass dot1q tags.
>> You should think about doing q-in-q to isolate your topology from the
>> customers.  What does your BGP look like?  Both L2VPN and VPLS are actually
>> BGP signalled so your (MP)BGP config is important too.
>>> 
>>> 
>>> 
>>> 
>>> 2012/3/22 Ben Boyd 
>>> A straight l2 circuit wouldn't work because of a switched-network
>> between a PE and the CE.
>>> 
>>> L2VPN wouldn't work because BGP isn't used as MPLS transport mechanism.
>>> 
>>> 
>>> Updated Setup:
>>> 
>>> CE switch #1 (untagged/tagged)  MX240 (11.4R1.14)  P
>> router  Cisco PE (tagged)  Switched Network  CE
>> switch #2 (untagged/tagged)
>>> 
>>> 
>>> 
>>> ---
>>> Ben Boyd
>>> b...@sinatranetwork.com
>>> http://about.me/benboyd
>>> 
>>> 
>>> 
>>> 
>>> On Mar 22, 2012, at 11:34 AM, Ben Boyd wrote:
>>> 
 
 All,
 
 I'm running into VPLS frustrations in an MX.  I'd like to create a
>> VPLS instance in which a customer can plug in a device on any port in our
>> network and we'll pass the traffic no matter what type of traffic it is
>> (we're just a wire).  For example, they can plug in a switch/router where
>> the interface is tagging traffic or not tagging traffic.
 
 This particular example is one CE-switch to another CE-Switch, but
>> we'll eventually add several additional switches and routers in the same
>> VPLS instance.
 
 Right now, I am seeing BPDU's received from one CE switch to another
>> CE switch, but I'm not seeing any coming back.
 
 I'm also not able to ping from CE to CE on any VLAN.
 
 Here is the Setup:
 
 CE switch #1 (untagged/tagged)  MX240 (11.4R1.14)  P
>> router  Cisco PE  CE switch #2 (untagged/tagged)
 
 CE switch #2 is receiving BPDUs from CE switch #1, however CE switch
>> #1 isn't receiving BPDU's from CE switch #2
 
 
 Relevant MX240 config:
 admin@interop-MX240# show interfaces ge-2/1/0
 mtu 9192;
 encapsulation ethernet-vpls;
 unit 0 {
family vpls;
 }
 
 
 admin@interop-MX240# show routing-instances VPLS2001
 instance-type vpls;
 vlan-id all;
 interface ge-2/1/0.0;
 protocols {
vpls {
no-tunnel-services;
vpls-id 100;
mtu 9216;
neighbor 172.16.0.11;
}
 }
 
 admin@interop-MX240# show protocols layer2-control
 mac-rewrite {
interface ge-2/1/0 {
protocol {
stp;
vtp;
cdp;
}
}
 }
 
 The VPLS VC is up from MX240 to Cisco PE.
 
 admin@interop-MX240# run show vpls connections
 Instance: VPLS2001
  VPLS-id: 100
Neighbor  Type  St Time last up  # Up
>> trans
172.16.0.11(vpls-id 100)  rmt   Up Mar 22 11:13:33 2012
>>1
  Remote PE: 172.16.0.11, Negotiated control-word: No
  Incoming label: 262151, Outgoing label: 119
  Negotiated PW status TLV: No
>>

Re: [j-nsp] ISIS Authentication Problems

[Aaron Dewell]

Have you tried knobs such as:

loose-authentication-check
level X no-csnp-authentication
level X no-psnp-authentication

The second two sound like what you might be looking for.  I have no CRS thus no 
further ideas...

Aaron

On Mar 7, 2012, at 7:53 PM, John Neiberger wrote:
> I'm pretty new to Juniper and I'm trying to troubleshoot a pretty
> weird problem between an MX960 running 9.6R4.4 and a CRS-8 running XR
> 4.0.4. It's a very straightforward ISIS configuration for IPv6. We
> have MD5 authentication configured on both sides. The adjacency comes
> up, but the Juniper doesn't learn any routes from the CRS and the logs
> complain about packets unexpectedly having a message digest. I'm not
> sure why they'd be unexpected.
> 
> The CRS is learning routes from the MX960, but it's critical that the
> reverse happen, as well. I just checked the logs and now I'm seeing
> messages about LSPs being ignored because they're missing
> authentication. I have a suspicion about what is happening, but I'm
> not sure. I think the CRS is only authenticating the hello packets but
> is not authenticating the LSPs, whereas the MX960 is expecting
> everything to have md5 headers.
> 
> I'm not ever sure that it's possible to configure IOS XR to only add
> md5 to the hellos but not the LSPs. This is really just a guess based
> on what I'm seeing. To enable md5 authentication in IOS XR, you add
> "hello-password hmac-md5 encrypted ##hashed text##" on the neighbor.
> That seems like it might actually be specific to the hellos and not
> necessarily the LSPs.
> 
> On the MX960, we have an authentication-key and authentication-type
> md5 configured. On a different router in our network, I see that
> someone has configured a different MX960 the same way, but they also
> added a hello-authentication-key and hello-authentication-type md5 to
> a specific neighbor.
> 
> This is all a little confusing because in that latter case I
> mentioned, the mix of routers is the same and the configuration
> between the two is the same as what I have, but the software is a
> little different. I'm wondering if I'm running into a bug or at least
> some quirky behavior. My MX960 is setting up the adjacency but
> dropping the other LSPs, but the other MX960 is not even though
> they're both connected to CRS.
> 
> Have any of you had any weird authentication issues like this?
> ___
> 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] Ex Series VC with *both* high-speed backbone *and* link-aggregation

[Aaron Dewell]

I haven't tried it, but all the docs I read on it suggested that configured
VC ports acted as more ports, not replacements. On our EXs, the normal VC
ports are still available even though we use two 10g for VC. However, we
aren't using them so i can't confirm... But pretty sure it should work.
 On Jan 3, 2012 11:37 AM, "Dave Peters"  wrote:

> Hi all--
>
> This is simple, but I can't find definitive proof online . . .
>
> Can I set up a Juniper EX series virtual chassis using a high-speed
> backbone on one floor of a building and then connect that VC to another
> switch (or two) via link-aggregation on the SFP ports?
>
> I'm not sure you can mix the VC connections, is all.  Can I use both the
> stacking backbone on one floor and the SFP links on another floor in the
> same virtual chassis?
>
> Thanks much.
>
> --
> Dave Peters
> Technical Director
> Terabit Systems
> 2565 3rd Street  #218
> San Francisco, CA  94107
>
> __**_
> 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] How does multihop eBGP work?

[Aaron Dewell]

Sure.  Everything is actually routed hop-by-hop.  As you've observed, that's a 
serious obstacle to multihop eBGP.

Most uses I've seen involve crossing a non-BGP router to a customer, and 
redistributing whatever the customer advertises into their IGP.  Klunky for 
sure, but it does work.

Aaron

On Jun 24, 2011, at 10:33 AM, Mike Williams wrote:

> Hey guys,
> 
> I've got a situation I think I need multihop bgp for (logical-systems and 
> bridge-domains).
> However it bugs me deeply that I don't "get" multihop BGP.
> 
> My biggest bugbear is if my multihop-ebgp peer tells me he know the best way 
> to x.x.x.x, the packets I send towards him must be routed by intermediaries, 
> will those intermediaries use their tables and "hijack" my packets down their 
> bits of wet string through 15 other ASs and to the moon and back?
> 
> Thanks
> 
> -- 
> Mike Williams
> ___
> 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