cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
10096
Views
0
Helpful
8
Replies

NX7009 - Checkpoint FW Layer 2 and Layer 3 topology?

gwhuang5398
Level 2
Level 2

We have two pairs of NX7009 and a pair of Checkpoint 12600. Checkpoint pair will be active/passive mode.

One pair of NX7009 will be connected to the Checkpoint pair in Layer 2 trunk. The other pair of NX7009 will be connected to the same Checkpoint pair but as Layer 3 connection.

In each pair of NX7009, one NX7009 will have a connection to one Checkpoint, and the 2nd NX7009 will have a connection to the other Checkpoint. For  Layer 2 trunking between NX7009 and Checkpoint, should we put the two NX7009 ports (one on each NX7009) into VPC? I'm not sure if that will work since Checkpoint only knows on active connection in active/passive mode.

For Layer 3 connection between Checkpoint and the pair of NX-7009, what's the best practice in doing that? I know it's not recommended to make NX7009 VPC port-channel as Layer 3.

Thanks for any suggestion

1 Accepted Solution

Accepted Solutions

happy to help , this is a very good link to start with as well

http://bradhedlund.com/2010/12/16/routing-over-nexus-7000-vpc-peer-link-yes-and-no/

and make sure to rate the helpful posts

regards,

View solution in original post

8 Replies 8

Leo Laohoo
Hall of Fame
Hall of Fame

Who's doing the routing?  Will you be running BGP from the Checkpooint?

Marwan ALshawi
VIP Alumni
VIP Alumni
                

    Hi

    L2:

    for the FWs connecting using L2 you can multi-home the L2 interfaces/links to both N7009 for vPC

    and use static routes on the FW to point to the relevant HSRP VIP in Nexus side while in nexus use static route to point to the active/VIP IP of the firewalls

    based on cisco recommendations using FWs with L2 interfaces:

      1. Dedicate a Layer 2 port-channel for the service appliances state and keepalive VLANs (we recommend that you do not use a vPC peer-link).

    or

      1. Connect service appliances to vPC domain via vPC and configure static routes to the HSRP/VRRP address on the service appliance side. On the Cisco Nexus 7000 Series side, create a static route pointing to the VIP of service appliance, routing concept can be done as bellow:

    On L3 service appliance, create a static route (it can be the default route) pointing to HSRP/VRRP VIP (Virtual IP) defined on vPC domain. This way, L3 service appliance (whichever one who is in active state) can send traffic to any vPC peer device. As both vPC peer devices are HSRP active (from data plane standpoint), they will be able to route traffic coming from the L3 service appliance.

    For the return traffic from vPC domain to L3 service appliance, create a static route on each vPC peer device

    pointing to static VIP defined on L3 service appliance. L3 service appliance VIP is identical for both active and

    standby instances. Only the active L3 service appliance instance owns the VIP (i.e process packets destined to

    VIP address).

    L3:

    if you want to use dynamic routing or static routing using L3 routed interface in the FW then between the FWs and the N7K you need to either:

    connect each FW to one N7K

    or multi-home them with L3 interfaces

    however it is recommend to use a separate L3 p2p interface between the N7K chassis for L3 routing/peering to avoid any routing/peering over the vPC-peer link and this will lead to some issues

    this is good link to start with

    [http://www.netcraftsmen.net/blogs/printblog.html?index_php?view=article&id=1216&tmpl=component&print=1 | http://www.netcraftsmen.net/blogs/printblog.html?index_php?view=article&id=1216&tmpl=component&print=1]

    hope this helps !https://supportforums.cisco.com/images/emoticons/happy.gif|___jive_emoticon_name=happy|jivemacro=emoticon|class=jive_macro jive_emote|src=https://supportforums.cisco.com/images/emoticons/happy.gif!

           

    Thank you very much for the detailed explanations. It helps a lot. Do you mind posting the link to the Cisco publication that has the above recommendations? They may have diagrams there that can help me too.

    Thanks again

    happy to help , this is a very good link to start with as well

    http://bradhedlund.com/2010/12/16/routing-over-nexus-7000-vpc-peer-link-yes-and-no/

    and make sure to rate the helpful posts

    regards,

    Happy to help and thanks for the nice rating

    Sent from Cisco Technical Support iPad App

    cafetog_cisco
    Level 1
    Level 1

    Hi,

    I got a similar issue. We also have Check Point installed, but this cluster handles several Virtual Firewalls into a cluster of physical hardware (box 1 and box 2):

    5 Virtual firewalls

    3 Virtual firewalls in box 1

    2 Virtual firewalls in box 2

    Each box has 2 interfaces with Link Aggregation connected to each Nexus in a vPC configuration.  Therefore, even one interface fails the network shouldn't have any service disruption.In that connection the N7k is the default gateway of the firewall.

    Whenever we stop Check Point services in one of the boxes (let's say box 2), all Virtual Firewalls failover to the active box (in this case box 1). However, we have noticed that the ARP table is not updated in both Nexus 7000 for some Virtual Firewalls although we see the gratuitous ARP leaving the firewalls interfaces.

    The only way to recover the service is to ping both Nexus' physical IP, because pinging the vPC VIP does not update the ARP table for both boxes.

    Do you have any idea what could be happening? Have you faced similar issues?

    Hello there:

    Our Checkpoint and Nexus will go in production mid January. I'll let you know how that goes then. Looks to me your Checkpoint and Nexus are connected as Cisco recommended. Are you running HSRP or VRRP on the pair of NX7K for the firewall Vlan interface?

    I'm not too familiar with Checkpoint. Are you using active/active failover mode or active/standby? If active/standby and assuming Checkpoint failover works the same way as ASA, its ARP would remain the same during failover, from NX7K's perspective (ASA's primary IP and MAC).

    Are you passing the firewall Vlan through the vPC peer link between the NX7K pair or through a separate trunk connection? Sounds like Cisco recommends a separate trunk for firewall Vlan, but in your connectivity, the fireweall Vlan is a vPC Vlan too.

    Thanks for your reply.

    We are running HSRP on the NX7k for the firewall Vlan interfaces.

    The virtual firewall technology (VSX) works as active/standby for each virtual firewall. Each pair of virtual firewall share the same IP addres, but the MAC address is the same as the physical box's. Therefore, if there is a failover there will be a MAC refresh in all adjacent devices (N7k among them).

    Some virtual firewalls are active in box 1 while the rest are active in box 2. From that point of view you can say that the whole solution distributes active virtual firewalls in both appliances, becomming an active/active solution. Only when one appliance fails, all virtual firewalls will become active in a single appliance.

    The other particular thing about Check Point is that besides a dedicated interface for synchronization with a massive amount of traffic (both connected to the same N7k, because we noticed some strange behaviour when connected to a vPC as you pointed out), it also sends state verication packets through all interfaces (tcp 8116). Those packets are sent to broadcast (layer 2) to a secondary IP address that it automatically configure per each production interface. So besides the configured IP address for the production environment, you can see another IP address used exclusively for state verification (usually 192.168.196.X, bear in mind not to use it nor route it).

    We are still stuck in the part whereby the pair of N7k do not update the ARP table. Somebody mentioned that Nexus using vPC do not have to share the same MAC table because they do not behave as a single device. Therefore the failover in this situation should not work as the firewalls have a different MAC address. However, it is not clear why it is only some virtual firewalls that lose conectivity in a failover event and not all of them... any further ideas?