Re: [j-nsp] Dealing with multihomed customer BGP primary/backup links

[Ross Halliday]

If I had no control over the far end I would enforce received routes with a 
prefix-list/routemap/policy (which you should be doing anyway), use 
metrics/localpref internally, and lock it down with strict uRPF.

However, my preferred approach is to place a CPE on site. We've never sold 
links on the basis of active/backup. We sell "redundant solutions". Gear is 
cheap, headaches aren't!

Cheers
Ross



> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of Cydon Satyr
> Sent: Wednesday, July 13, 2016 4:37 AM
> To: juniper-nsp@puck.nether.net
> Subject: [j-nsp] Dealing with multihomed customer BGP primary/backup links
> 
> What would be the optimal way to deal with following scenario.
> 
> The customer of ours has a primary bgp connection over primary link on one
> router, and a backup bgp connection (up) on backup link on our other
> router. The customer may or may not (usually not) terminate both
> primary/backup links on the same router.
> 
> We want to stop customer using backup link at all as long as the primary
> link is up. Since we police both primary and backup link, customer can
> just
> load balance and use both links.
> 
> Without asking changes on his side (so something link MC-LAG won't fit
> here, I guess?), what are way to deal with this.
> 
> I can think of making a script which will not import their routes as links
> a primary link route is in our table.
> 
> The bgp conditional policy doesn't work for importing routes, only
> exporting... so that won't work either.
> 
> Any other suggestions maybe?
> 
> Regards
> ___
> 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] repartition HDD in RE-333-768

[Martin T]

Hi,

on a second thought, "request system partition hard-disk" and then
"request system reboot" seems to work as well in that case:

root@m5> request system partition hard-disk
WARNING: Could not read disklabel for s1.
WARNING: Default sizes will be used for hard disk partitions.

WARNING:   The hard disk is about to be partitioned.  The contents
/* output removed for brevity */


This did not work on my test box where MBR was wiped:

root@mx480> request system partition hard-disk
mount: /dev/ad1s1e : No such file or directory
ERROR: Can't access hard disk, aborting partition.

root@mx480>


With this method only one reload is required.


thanks,
Martin

On 7/15/16, Martin T  wrote:
> Hi,
>
> I have a situation on a remote live router where /dev/ad0s1a
> partition(in FreeBSD terminology) on CF is larger than /dev/ad1s1a
> partition on HDD. In addition /dev/ad0s1e partition is larger than
> /dev/ad1s1e. This means that I'm not able to create a snapshot to
> alternative media. What I need to do is "request system snapshot
> partition", but this is not possible because /dev/ad1s1f is mounted on
> /var. I could unmount the /var, but then the mgd is killed which means
> that I can't execute "request system snapshot partition". Best method
> I could come up with is to change the value of kern.geom.debugflags
> temporarily from 0x0 to 0x10(sysctl kern.geom.debugflags=0x10) in
> order to allow writes to MBR, wipe the MBR(dd if=/dev/zero of=/dev/ad1
> bs=512 count=1) and then reload the router(reboot). During the boot it
> will mount emergency /var to memory file-system and one is able to
> execute "request system snapshot partition". Then again router needs
> to be reloaded so that /dev/ad1s1f is mounted under /var and swap
> space is used. This last step can be done using mount and swapon as
> well.
>
> However, is there some quicker or even non service-affective way to
> solve this problem?
>
>
> thanks,
> Martin
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] repartition HDD in RE-333-768

[Martin T]

Hi,

I have a situation on a remote live router where /dev/ad0s1a
partition(in FreeBSD terminology) on CF is larger than /dev/ad1s1a
partition on HDD. In addition /dev/ad0s1e partition is larger than
/dev/ad1s1e. This means that I'm not able to create a snapshot to
alternative media. What I need to do is "request system snapshot
partition", but this is not possible because /dev/ad1s1f is mounted on
/var. I could unmount the /var, but then the mgd is killed which means
that I can't execute "request system snapshot partition". Best method
I could come up with is to change the value of kern.geom.debugflags
temporarily from 0x0 to 0x10(sysctl kern.geom.debugflags=0x10) in
order to allow writes to MBR, wipe the MBR(dd if=/dev/zero of=/dev/ad1
bs=512 count=1) and then reload the router(reboot). During the boot it
will mount emergency /var to memory file-system and one is able to
execute "request system snapshot partition". Then again router needs
to be reloaded so that /dev/ad1s1f is mounted under /var and swap
space is used. This last step can be done using mount and swapon as
well.

However, is there some quicker or even non service-affective way to
solve this problem?


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

Re: [j-nsp] vSRX Policy-based VPNs - unsupported platform

[Chris Burton]

Pretty sure policy-based VPN was unsupported for a short period during 
the transition from older code and hardware to the newer, but should be 
back in 15.1X49-D50, though I do not know the version of the current 
trial software available for download.


-C

On 07/15/2016 12:28 AM, Jed Laundry wrote:

Hi Folks,

I'm looking at converting our aged hardware SRX's onto vSRX, but I
seem to have hit a big scary warning when staging config for
policy-based VPNs, see below:

security {
 policies {
 from-zone zone-lab to-zone zone-internet {
 policy policy-test-ipsec {
 match {
 source-address addr-lab-testbox;
 destination-address addr-remote-testbox;
 application any;
 }
 then {
 permit {
 ##
 ## Warning: configuration block ignored:
unsupported platform (vsrx)
 ##
 tunnel {
 ipsec-vpn vpn-remote;
 }
 }
 }


This is vSRX 15.1X49-D40.6 on VMware. It's just the trial version, I
haven't bought a licence yet.

I haven't yet been able to test if this does or doesn't work (next
week), but the warning doesn't look good.

Is anyone else using vSRX with policy-based VPNs?

Is there something fundamental that I've missed, or a configuration
tweak necessary to convert 12.1 config to 15.1?

Thanks,
Jed.
___
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] vSRX Policy-based VPNs - unsupported platform

[Dale Shaw]

Hi Jed,

On 15 July 2016 at 17:28, Jed Laundry  wrote:
>
[...]
> ##
> ## Warning: configuration block ignored:
> unsupported platform (vsrx)
> ##
> tunnel {
> ipsec-vpn vpn-remote;
[...]
>
> This is vSRX 15.1X49-D40.6 on VMware. It's just the trial version, I
> haven't bought a licence yet.

According to the release notes, policy-based VPN support was
(re-)introduced from 15.1X49-D50.

See:
http://www.juniper.net/techpubs/en_US/junos15.1x49-d50/information-products/topic-collections/release-notes/15.1x49-d50/junos-release-notes-15.1X49-D50.pdf

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

[j-nsp] vSRX Policy-based VPNs - unsupported platform

[Jed Laundry]

Hi Folks,

I'm looking at converting our aged hardware SRX's onto vSRX, but I
seem to have hit a big scary warning when staging config for
policy-based VPNs, see below:

security {
policies {
from-zone zone-lab to-zone zone-internet {
policy policy-test-ipsec {
match {
source-address addr-lab-testbox;
destination-address addr-remote-testbox;
application any;
}
then {
permit {
##
## Warning: configuration block ignored:
unsupported platform (vsrx)
##
tunnel {
ipsec-vpn vpn-remote;
}
}
}


This is vSRX 15.1X49-D40.6 on VMware. It's just the trial version, I
haven't bought a licence yet.

I haven't yet been able to test if this does or doesn't work (next
week), but the warning doesn't look good.

Is anyone else using vSRX with policy-based VPNs?

Is there something fundamental that I've missed, or a configuration
tweak necessary to convert 12.1 config to 15.1?

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