PBR Configurations in ACI

[losharm]

Can anyone help me with the PBR configurations in ACI without using L4-L7 

[Sergiu.Daniluk]

Hi @losharm 

You can't do PBR without service graphs. You can however use VRF sandwitch + L3Outs, to force traffic through your L4L7 device, but that is not PBR.

Take care,

Sergiu

[RedNectar]

Hi @losharm ,

What exactly are you trying to do with PBR?

In the ACI sense, PBR intercepts traffic flowing through a contract, and if it matches your criteria for redirection, places the MAC address of the target device (typically a FW or load balancer) in the DA of the frame, and sends it on a path towards the target device. That's the short story anyway.

Now, if you have other - non L4-7 reason for wanting to do this, there may be some scope, but without knowing exactly what you are trying to achieve, it is impossible to answer. 

[losharm]

Hi RedNectar,

Can you please share with me the exact procedure to achieve the below scenario?

Host A from DC-1 want to communicate with Host B in DC-2 but it needs to pass from a specific gateway. Just like we do in the traditional networking. Device forward the packet based on the policy configured with looking in the routing table. Means wants to redirect some of the traffic.......

Response Awaited 

Thank You 

[RedNectar]

Hi @losharm ,

Sounds like you want to make a simple "VRF Sandwich" as @Sergiu.Daniluk suggested.

Here is one of MANY possible "exact procedures" - for simplicity I've enable preferred groups to avoid having to create contracts.

1. Create Access Policy Chains for the interfaces where Host A, Host B, L3OutA and L3OutB connect to ACI
2. Create a Tenant
3. Inside the Tenant:
   1. Create VRF.A
   2. Enable Preferred Groups for VRF.A
   3. Create BD.A linked to VRF.A
      1. Assign BD.A and IP address that is the default gateway of Host A. I've used 1.1.1.1/24 in the diagram
   4. Create VRF.B
   5. Enable Preferred Groups for VRF.B
   6. Create BD.B linked to VRF.B
      1. Assign BD.B and IP address that is the default gateway of Host B. I've used 2.2.2.1/24 in the diagram
   7. Create an Application Profile (Not shown in diagram for clarity)
      1. In the Application Profile:
         1. Create EPG.A
            1. Enable the Preferred Group for EPG.A
            2. Statically map the interface/VLAN where Host A connects to the EPG
         2. Create EPG.B
            1. Enable the Preferred Group for EPG.B
            2. Statically map the interface/VLAN where Host A connects to the EPG
   8. Create L3OutA linked to VRF.A
      1. Enable the Preferred Group for L3OutA
      2. In L3OutA configure Router ID, routing protocol (or static routes) and appropriate IPs that match your external router side A
   9. Link BD.A to L3OutA (under L3 configuration)
   10. Create L3OutB linked to VRF.B
       1. Enable the Preferred Group for L3OutB
       2. In L3OutB configure Router ID, routing protocol (or static routes) and appropriate IPs that match your external router side B
   11. Link BD.B to L3OutB (under L3 configuration)
4. Apply what ever policies you want on the external router
5. Validate that Host A can communicate with Host B according to the policies configured on the external router

[losharm]

In the above scenario, every traffic is going via L3out-1 where the default route is given and using next hop 20.1 but the condition is if SIP- 10.10.10.10 and DIP is 14.14.14.14 then the next hop should be 30.1 and traffic pass via L3out-2 instead of L3out-1. How can we achieve this via ACI? Please explain.....

[RedNectar]

Hi @losharm ,

I assume that the route to 14.14.14.14 is already being advertised by R2 (or you have a static route)

So all you need to do is add a L3EPG to the L3Out with a subnet of 14.14.14.14/32, then add a contract between the EPG with the 10.10.10.10 endpoint and the L3EPG.

Also remember that L3Outs are configured on a Leaf switch - unlike EPGs which are configured as a model and pushed to leaves when required. Might seem like a small difference, but it is important when it comes to interpreting how routes are learned from outside.

Now, IF there are other endpoints in the same EPG as 10.10.10.10 that should NOT have access to 14.14.14.14, then you will have to move 10.10.10.10 to a NEW EPG liked to the same BD (where 10.10.10.1 lives). This will also mean changing the VLAN (or portgroup) that 10.10.10.10 currently uses.  And if you want 10.10.10.10 to communicate freely with all the other endpoints in the OLD EPG, then create a contract between the OLD and the NEW EPGs