Fusion Firewall with Intermediate L3 Hop

[techno.it]

We are deploying the similar design as shown in the attached picture ( source: Cisco Live) where we have Nexus vPC switch as L3 hop between Border and Firewalls.

BGP sessions will be established directly between:

Border Nodes and Nexus
Nexus & Firewalls ( Active/Standby)
I was wondering what BGP peering relationship will be formed between Nexus and Firewall (iBGP or eBGP) and should they have different have AS, if EBGP.

For example

Border Nodes: AS 65001
Nexus: AS 65002
Firewalls: AS 65003

I would appreciate any advise or corrective design.

[Andrii Oliinyk]

Is it green field of vPC is being used currently for some legacy purposes?
rephrasing Q above: do u really need NX-OS vPC in between instead of SVL'ed consolidated BN|CP directly connected to FW A/S?

[techno.it]

Yes its greenfield deployment.

We studied couple of options:

1- If we connect FW directly and make BGP peering with BNs, FW shall received equal routes from BNs. Firewall needs to have ECMP enabled but this would stop Multicast and we need Multicast

2- Stack border which has no support for ISSU upgrade, making SPOF

3- Not still considered Border Active/Passive scenarios.

Appreciated any recommendation and suggestions

[Andrii Oliinyk · Accepted solution]

1. Didnt get clearly about conflict between ECMP & Multicast frankly saying... & How peering with intermediate NX-OS resolves it.
2. Then use NX-OS vPC as L2-switch (u'll avoid vPC 'gotchas' doing like this)
3. FW will still have 2 eBGP peerings & there is a broad means to manipulate A/A or A/S scenarios.

[techno.it]

1. Please check this Cisco Live Session On-Demand Session Library - Cisco Live On-Demand - Cisco. You can fast forward to 1:02:00

2. Firewall will have only  1 single physical connectivity and peering with Nexus Switch and will only install single route

[Andrii Oliinyk]

1. please assist with slide # in PDF-preso. UPD. i've found it. it's about the case where MC-speaker is within Fabric & MC-listener somewhere on the north behind the FW. u need to pay attention to RPF check on FW as it may drop MC-packets arriving from unexpected interface . But if you MC-speaker on the north u not need to worry.
2. i'm more than sceptical about this statement. with what IP on the vPC u are going to have single session from FW side? 

[techno.it]

1. Page 40 ciscolive.com/c/dam/r/ciscolive/global-event/docs/2024/pdf/BRKENS-2824.pdf

2. May be as following for VRF-X

BN 1 to Nexus vPC VLAN 3001 - 172.16.1.0/30

BN 2 to Nexus vPC VLAN 3002 - 172.16.1.4/30

Nexus vPC to FW ( Active FW - Trunk Port) - VLAN 3003 - 172.16.1.8/30

[Andrii Oliinyk]

so u peer BN1 with N1 & u peer BN2 with N2, right? how do u peer N1&N2? & how do u peer vPC with FW? vPC is 2 independant control planes. u cannot peer with them in single session.
Shortly, u wont avoid 2 sessions between FW & vPC (1 session per vPC-peer). with this said u either use vPC purely for L2-switching or u fallback to diagram on slide#39.

[techno.it]

Apology for my ignorance and confusion. I was expecting vPC sharing same control plane as SVL.

If I decided to take on approach to use vPC purely for L2 or to connect firewalls directly with BNs, how we can overcome ECMP & Multicast limitations so then only option to make Border node active passive.

[Andrii Oliinyk]

"...how we can overcome ECMP & Multicast limitations so then only option to make Border node active passive"
by making one of the BNs fully "backup" (LISP preference on the Primary node, worstening path to the north from perspective of "backup" BN & worstening path to the Fabric via "backup" BN from FW perspective. ECMP between FW & BNs is not required actually.

[techno.it]

by making one of the BNs fully "backup" (LISP preference on the Primary node, worstening path to the north from perspective of "backup" BN & worstening path to the Fabric via "backup" BN from FW perspective. ECMP between FW & BNs is not required actually.

You mean the settings defined here on page 39?

https://www.ciscolive.com/c/dam/r/ciscolive/global-event/docs/2024/pdf/BRKENS-2824.pdf

[Andrii Oliinyk]

yup

[techno.it]

Thanks

To confirm on number of VLANs & Peering per VRF

Example:

VRF-Y

Transit VLAN 3001 on BN1 & BN2 - 172.16.1.0/29

FW dot1q trunk port sub interface Int Gi0/1.3001 ( Zone VRF-Y)

BN1 IP: 17.16.1.1

FW IP: 172.16.1.2

BN2 IP: 172.16.1.3

BN1-FW- Peering1

BN2-FW- Peering2

Please correct me if I’m mistaken

[Andrii Oliinyk]

u may place peering entities in single subnet like above if u use L2-switch in the middle. if u connect FW directly to BNs (obviously with different phy links) u will use /3[01] 

[techno.it]

Thank you @Andrii Oliinyk. I appreciate it