Comware Based
1752708 Members
5862 Online
108789 Solutions
New Discussion

Re: Policy Based Routing in A5820X

 
SOLVED
Go to solution
frekn0
Occasional Collector

Policy Based Routing in A5820X

Hi All,

 

 

Question regarding Policy Based Routing. First time I make use of the functionality and I wonder whether what I'm hoping to achieve is possible :) We are changing ISPs and I was hoping to test the new connection from a specific subnet. Routing is obviously set up to use the current ISP and I would like to make an exception to this. 

 

I'm looking for a way to route Internet bound traffic from Subnet A through a different (default GW) while sending (local) traffic to CorpNet down a different route. 

 

So, a combination of routes that I can define (CorpNet 10.x.x.x) and a general, catch all, defined range (Internet). I have got parts of it working, but I come up against different restrictions (e.g. only one policy per interface) and I can't seem to figure out how to build a configuration to handle the if/else, if you will, scenario of all traffic except for local (CorpNet) should use different gateway. I got the furthest by using an ACL if-match clause, but how do I combine or (possibly) build a destination is NOT CorpNet, then type rule. In my attempts I have associated my PBR with the vlan-interface of Subnet A. 

 

 

Best regards,

Fredrik 

4 REPLIES 4
Ian Vaughan
Honored Contributor

Re: Policy Based Routing in A5820X

Hi,

This is a pretty good step by step guide using the classifier and behavior mechanism:

PBR example

 

Cheers

Ian

Hope that helps - please click "Thumbs up" for Kudos if it does
## ---------------------------------------------------------------------------##
Which is the only cheese that is made backwards?
Edam!
Tweets: @2techie4me
frekn0
Occasional Collector
Solution

Re: Policy Based Routing in A5820X

I spent some more time on this "challenge" and believe I came up with a working configuration! 

 

Found a bullet in one sample configuration saying "If packets that match a policy node do not need to be forwarded according to PBR, specify deny match mode for the policy node". I replicated this in my configuraton and noticed that the switch started to treat my traffic the way I wanted. 

 

I have configured two ACLs, one matching traffic from subnet A to local (CorpNet) subnets and one matching traffic from Subnet A to any destination (Internet). I then built one PBR with two nodes based on the two ACLs, the first node is set to deny match mode. The other is set to permit and applies an alternative next-hop address (my new ISP).  Lastly, applied the PBR to the VLAN interface of Subnet A.

 

/f

 

acl number 3005
rule 5 permit tcp source {Subnet A} 0.0.0.255 destination {CorpNet}
 
acl number 3006
rule 5 permit tcp source {Subnet A} 0.0.0.255


policy-based-route PBR1 deny node 1
if-match acl 3005
apply ip-address next-hop {IP-address of A5820X}
quit

policy-based-route PBR1 permit node 5
if-match acl 3006
apply ip-address next-hop [NewISP_GW}
quit

 

Apachez-
Trusted Contributor

Re: Policy Based Routing in A5820X

Personally I would put these clients in their own VLAN and tag this all the way towards the new ISP (where it gets untagged), the routingtable would be handled as a VRF (vpn-instance in comware lingo) - but I assume your case was that these clients would still be able to reach the other resources of your internal network, you just wanted to change where their default route would go?

frekn0
Occasional Collector

Re: Policy Based Routing in A5820X

Hi,

 

 

Thanks for responding. Yes, that would definitely be an alternative and something to pursue - especially for me as it would give me a chance to get (more) familiar with VRF as a technology :) However, in this case you are right I need the clients to be able to communicate with other resources as well. It is more a matter of changing the default GW temporary during the transition to test the connectivity and configuration. Also, I don't have VRF running on the switch today so I believe it would require some additional configuration work that I will have to reverse later. 


Thanks again,

Fredrik