Screen OS

I currently have a NSRP configuration w/ the ISP providing a handoff w/ a static ip address and a default route pointing to the carrier equipment.  The carrier has advised that they will be moving this connection to a BGP implementation so I'll need to update my side to match.  I've seen that I'll need to add this:

Set vr untrust protocol bgp MYASNumber
set vr untrust-vr protocol bgp enable
set vrouter "untrust-vr" protocol bgp neighbor 1.1.1.1 remote-as MYASNumber local-ip 172.27.201.135/32
outgoing-interface e0/3
set vr untrust-vr protocol bgp neighbor 1.1.1.1 enable
set interface e0/3 protocol bgp

Is that all that's needed on the SSG140?

Yes, that is all that is needed for a basic peering session.

This is the document that will help find the issue if the session does not come up.

[ScreenOS] How to troubleshoot BGP issues

https://kb.juniper.net/InfoCenter/index?page=content&id=KB21496

Thanks Spuluka.  I'll review and use it at time of install. 

BTW, if I need to advertise a block a /28 network to my BGP neighbor so they'll advertise it out can I just use this:

FW(untrust-vr)-> set protocol bgp
FW(untrust-vr/bgp)-> set network AA.BB.CC.0/28

and is anything special needed for a NSRP setup?  

In addition, you will also need to create the appropriate route map and apply this to the neighbor.

Also bear in mind that an import policy on the neighbor can prevent routes from being learned as well.

[ScreenOS] BGP configuration to restrict the routes being advertised to any BGP neighbor

https://kb.juniper.net/InfoCenter/index?page=content&id=KB23528

Ok, this is currently set for tomorrow.  I just go the ip information from the ISP and from what I'm seeing they'd like SSG140(A) to use an ip of a /30 directly connected to their equipment and SSG140(B) to use an ip of a /30 directly connected to another router.  Is this possible w/ an NSRP configuration (basically from the looks of what the ISP sent, they expect one unit to have x.x.x.250/30 and the other unit to have x.x.x.254/30) since I thought the configuration would have to be identical between the 2 units?

You probably have this all worked out now.  But the answer depends on how your cluster is setup.

Normally in Active/Passive clusters there is just one address and one peer and the BGP session will failover with all the data during an event.  Naturally you need a switch vlan to connect the three ports together so that communication can occur.

For the dual peer your cluster will need to be active/active and then you can have independant sessions on each device.

Actually this is still on hold.  So I'd be able to do Active/Active and split out the one interface on each unit for the BGP configuration and then have the remaining traffic pass through SSG-1 until it fails, then out SSG-2?  Would I have to manually maintain the configuration on each (like in VRRP) or would the configuration still be shared between them?

With ScreenOS NSRP clusters you don't need configure VRRP, the failover between interfaces is part of the clustering.  And the two nodes do back each other up for the main flows.

This document gives the overview and flow examples for both Active/Passive and Active/Active clusters.  The configuration link is at the bottom.

http://kb.juniper.net/InfoCenter/index?page=content&id=KB4263

Thanks Spuluka.  Would something like this work (using static routing for now, will have to modify for BGP):

Device A
set nsrp cluster id 1
unset nsrp vsd-group id 0
set nsrp vsd-group id 1 priority 1
set nsrp vsd-group id 1 preempt hold-down 10
set nsrp vsd-group id 1 preempt
set nsrp vsd-group id 2
set nsrp vsd-group id 1
set nsrp monitor int eth1/2
set nsrp monitor int eth2/1
set nsrp rto-mirror sync
save

Device B
set nsrp cluster id 1
unset nsrp vsd-group id 0
set nsrp vsd-group id 2 priority 1
set nsrp vsd-group id 2 preempt hold-down 10
set nsrp vsd-group id 2 preempt
set nsrp vsd-group id 1
set nsrp monitor int eth1/2
set nsrp monitor int eth2/1
set nsrp secondary-path ethernet2/1
set nsrp rto-mirror sync

set int ethernet1/2 zone untrust
set int ethernet1/2:1 ip 1.1.1.2/30
set int ethernet1/2:2 ip 1.1.1.6/30

set vrouter trust-vr route 0.0.0.0/0 interface ethernet1/2:1 gateway 1.1.1.1
set vrouter trust-vr route 0.0.0.0/0 interface ethernet1/2:2 gateway 1.1.1.5
save

And then cable Device A Eth1/2 to one of the carriers routers and Device B Eth1/2 to the other?

You need to put the two ip addresses onto different interfaces.  The two VSD groups are used on the same interface when you have addresses in the same subnet that can be used for failover on that specific interface.  This would be where the traffic for that link will go when the primary VSD group device fails.

In your case you have only a /30 single link so there can be no failover for that interface and thus both have to be on differerent interface numbers on the two devices and have no partner interface for failover.

Ok thanks.  I kinda realized what I posted wasn't right shortly after I posted.  I think i understand how it needs to be configured, but still have an issue in terms of how I'd finalize some of the configuration.  If my ISP is giving me 2 /30 so the WAN interface ips, and intended to route a /28 block to me, would I be able to use the block on both WAN interfaces for MIPs?  There are a number of web servers that sitting behind the SSG so would be trying to maintain access to those services in the event of a failover if possible. 

You can place these two interfaces into the same zone and have both work with the /28 from your ISP.   

You will need this routed to both interfaces or you will need to use the BGP to adverstise the /28 up to the ISP on both peers.

Thanks.  Would it be possible to use a loopback interface and have both WAN links as part of the loopback group. Then configure the MIP on the loopback interface?  As it stands the carriers states they have to use 2 /30's so I was thinking of putting 2 switches (1 for each pair of interfaces on the 140s) and configuring both /30's in the configuration.  Then advertise the /28 block into bgp.  

I've not used the loopback group myself, but the setup you describe is exactly what they seem to be created for with the sharing of a MIP between multiple interfaces.  This should work well.

The other method is to use policy based destination NAT.