Network segmentation via nexus using VRFs and virtual router Palo alto with BGP peering

[Sukhmeet]

Requirement: have to make firewall config based on network configuration done on Nexus. My challenge is Communication is not posoble with network guys coz they are Chinese, customer speak different language as well. 

OBJECTIVE: we want DC firewalls to be used for filtering or traffic only and nexus to do the core routing..

In the config I can see that VRFs are created and for ebgp peering of core switch with firewall I can see each VRF peer IP is different please see attached screenshot. 

After seeing this config i decided to make virtual routers for each VRF and do bgp peering between VRF and VR and the reason is decided this is coz each VRD"this all in design phase" 

My question is.. Is it possible to peer multiple VRFs with single virtual router? And establish ebgp with it? If yes, what changes you think network team should make on core switch or none?

Coz my understanding is that since the peer IPs in each VRF is different for the firewall AS.. Palo alto single virtual router won't be able to establish since we need to have unique address on both side for one AS and with single VR it's not possible..

Appreciate if someone can give feedback. Or correct approach.  

[aleksandar.astardzhiev]

Hi @Sukhmeet 

-  "Palo alto single virtual router won't be able to establish since we need to have unique address on both side for one AS and with single VR it's not possible" - That is not true. Firewall doesn't care if there its neighbors are on single device in different VRFs, or separate physical devices. You can have multiple BGP peers to the same AS. AS is configured on virtual-router level, so any interface assigned to that VR can be used to establish BGP peering and be part of t he same FW AS.

- "Is it possible to peer multiple VRFs with single virtual router?" - Yes, as I mentioned above, firewall doesn't care if you use VRFs or not. VRF is local configuration, that effect how this device is managing it routing table, once the packet is forwarded to the next device, it really doesn't matter. The only requirement is that the networks that you will use for the BGP peering to be unique and not overlap each other. It is not clear from your picture, but I assume you will use /30 networks, which is perfectly fine.

- "And establish ebgp with it?" - Yes, you shouldn't have any issues establising BGP peering with each VRF from the same VR, as long as you use non-overlapping networks for the peering.

Unfortunately there is, but....

If you plan only to receive routes from each VRF and only advertise default (or any other prefix that originale only from FW) to them, this also should be fine.

The problem is that all of these peers are in the same AS, which could cause you issues if you need to advertise routes received from one VRF to any of the other two. This is because the loop prevention build-in to the BGP protocol - router will reject any prefix that receive if it sees his own AS number in the AS path.

So if you need to advertise routes from WEB-PROD VRF to APP-DB-PROD, by default firewall will accept the routes, install them in its own routing table, advetise them to APP-DB-PROD, but Nexuss switch will reject them, because it will see it own AS number in the path (because the prefix originates from WEB-PROD, which is in the same AS).

There is a solution for that - Palo Alto gives you option to remove AS from the AS path using Import rules, when receiving the prefixes - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClEkCAK As you can see it support RegEx, but in your case it doesn't matter, as you only need to remove one AS number.

- Create Import rule that will be used for peering with WEB-PROD VRF

- Enter the AS number of nexsus (optional list the expected prefixes)

- For action select "allow" and choose "remove" under AS Path

- Create similar Import rules for the other two BGP peering. Or you can use same import rule, but choose all peers. (I like to use separate, so I can controll what prefixes to allow or reject from peers)

Of course you can go with your approach - separate VR for each VRF if your design requires total separation of networks and doesn't need to route between VRFs. If you decide that you need to route between VRFs,

- you will need to create static routes pointing to next-vr and have those static routes redistributed into BGP.

- or you can build BGP between your VRs and redistribute between BGP processes - https://knowledgebase.paloaltonetworks.com/kcSArticleDetail?id=kA10g000000ClIp

In both cases you will need to redistribute the prefixes, which will wipe out the AS path, so the loop prevention wouldn't be a problem and you don't need to remove AS.

So basically both ways should work, so it is up to you which one you find more suitable for you. I personaly have real experience with first option and use single VR with Import rules to remove neighbour AS from the path, so I can advertise routes between VRFs.