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 <jason-j...@lixfeld.ca> 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 <aaron.dew...@gmail.com> 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 <jason-j...@lixfeld.ca> 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 <aaron.dew...@gmail.com> 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 <jason-j...@lixfeld.ca> 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 <aaron.dew...@gmail.com> 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 <jason-j...@lixfeld.ca> 
>>>>>>> wrote:
>>>

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 <jason-j...@lixfeld.ca> 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 <aaron.dew...@gmail.com> 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 <jason-j...@lixfeld.ca> 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 <aaron.dew...@gmail.com> 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 <jason-j...@lixfeld.ca> 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 <clin...@scripty.com> 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

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 <jason-j...@lixfeld.ca> 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 <aaron.dew...@gmail.com> 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 <jason-j...@lixfeld.ca> 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 <clin...@scripty.com> 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 <lis...@esds.com.br> 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 <aaron.dew...@gmail.com>:
>> 
>> 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 <lis...@esds.com.br> 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 <bitkr...@gmail.com> wrote:
> 
> Hi Aaron,
> 
> On Sun, Jun 26, 2016 at 11:19 AM, Aaron Dewell <aaron.dew...@gmail.com 
> <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 <bitkr...@gmail.com 
> >> <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 v...@mpeks.tomsk.su 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]

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 r...@futomaki.net 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] Buying a used Juniper

[Aaron Dewell]

Ask your local reseller for a quote.

On May 5, 2015, at 2:13 PM, Colton Conor colton.co...@gmail.com 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 damien.devi...@gmail.com
 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=contentid=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 colton.co...@gmail.com
 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 colton.co...@gmail.com
 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 r...@futomaki.net
 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] 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 n...@schmalenberger.us 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 darre...@outlook.com 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 v...@mpeks.tomsk.su 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] 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]

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 molas...@gmail.com 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] 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 bd...@comlinx.com.au:
 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 molas...@gmail.com 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 bd...@comlinx.com.au
 
 On 16 Jan 2014, at 11:22 am, Samol molas...@gmail.com 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
 OSPF on SRX clustering.png
 
 
 
 
 -- 
 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 mihaigabr...@gmail.com
 mailto:mihaigabr...@gmail.com 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)
 Indirect next hop: 0 - INH Session ID: 0x0
 State: Active Int Ext
 Age: 22:36  Metric2: 1
 Validation State: unverified
 Task: mihai-vpls-l2vpn
 

[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 kwo...@citywest.ca 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-nsphttps://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] 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 jtroo...@nexdlevel.com 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] 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 bbuch...@nexicomgroup.net 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 gateway – 192.168.20.224 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]http://messaging.nexicom.net/demo/callme.html?Token=%2BMG4FqUv2NeHeDa1hskfYtfJuno3cQZPLYABdYJ%2FSzqBopBqHiON5tp2gJxEFzvYJEVgFhguIyM94VT%2F5gSYKQPnNXfHtvtV4SL6WuBmtmrG9lu3W5DQJcNnjVetEwcMmynAZcsFspCj4zNyGZPVNQ9cD3MGYjzhJDuAztmmlY30X%2BInJFzGAIlxND9W0RghG63yJ4vYC%2BrYtAv33AYFzjqErh1nzDUutVR6cmGs%2BS9ymGDFRZ80IXTOm%2FRWr5AdjBr4L8EUO6tadfT3JSWBZdN1U9hDimBYYZgNaSPOUFLZBq5uwsyU%2Bf67gYm0NPIV6kggg%2B59ypWRWTDccFUF6ph3msB0k83cnY3FAWynyM5w2BYZZQmFIXVBCTMjkE01ulNAUnyyZh%2BMLmKXuci9RmrF1kq7tvNcCOtEFvYckpBHUjyH6%2FtX9wjXqATwcmgNU7ZVPdG5JvhdwS4m5tlusg%3D%3D
 

 ** **

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

image001.png___
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 jsm...@windmobile.ca 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  

 * *

 http://www.windmobile.ca/ 
 http://www.facebook.com/WINDmobilehttp://www.twitter.com/WINDmobile
 

 http://www.windmobile.ca/

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

image002.pngimage001.pngimage003.pngimage004.png___
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
 image001.jpg
 
 
 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=contentid=KB19829actp=searchviewlocale=en_USsearchid=1365002153257
 
 Apparently, high end SRX isn't supporting IKE unless it's via a RETH 
 interface. RANT WHAT THE FREAKING HELL/RANT
 
 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 dickeypj...@yahoo.com 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

[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 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

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=contentid=KB17947  and started 
 to have some heart palpitations.  It seems a complicated procedure fraught 
 with peril.  Anyone out there have any thoughts (positive/negative) on their 
 experience on upgrading an SRX cluster with minimal downtime?
 
 thanks!
 -andy
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp


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

Re: [j-nsp] SRX upgrade procedure -ready for enterprise?

[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=contentid=KB17946actp=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
 andy.litzin...@theplatform.com wrote:
 We're evaluating SRX clusters as replacements for our aging ASAs FO pairs in 
 various places in our network including the Datacenter Edge.  I  was reading 
 the upgrade procedure KB: 
 http://kb.juniper.net/InfoCenter/index?page=contentid=KB17947  and started 
 to have some heart palpitations.  It seems a complicated procedure fraught 
 with peril.  Anyone out there have any thoughts (positive/negative) on their 
 experience on upgrading an SRX cluster with minimal downtime?
 
 thanks!
 -andy
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp


___
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=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500
options=23RXCSUM,TXCSUM,TSO4
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 full-duplex,flow-control)
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 skeeve+juniper...@eintellego.net
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 ;  http://twitter.com/networkceoau
 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 c...@wpi.edu 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

[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 R6's loopback

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

R6's loopback/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

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 aaron.dew...@gmail.com 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 R6's loopback
 
 inet.0:  destinations,  routes ( active, 0 holddown, 4 hidden)
 + = Active Route, - = Last Active, * = Both
 
 R6's loopback/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

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 aaron.dew...@gmail.com 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

[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

[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] 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 aaron.dew...@gmail.com 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

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 gau...@gausus.net 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 b...@sinatranetwork.com 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 b...@sinatranetwork.com
 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
  Local interface: lsi.1052423, Status: Up, Encapsulation: ETHERNET
Description: Intf - vpls VPLS2001 neighbor 172.16.0.11 vpls-id
 100
 
 
 Cisco_PE#show mpls l2transport vc
 
 Local intf Local circuit  Dest addressVC ID
 Status
 -  -- --- --
 --
 VFI vpls1  VFI

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 d...@terabitsystems.com 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-nsphttps://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