Start a Conversation

Unsolved

This post is more than 5 years old

1677

January 3rd, 2018 10:00

S4048T-ON PBR redirect list - is DENY possible?

Hello everyone

I have Dell S4048T-ON switch with firmware 9.11(2.1).
I am trying to implement PBR to allow some IP addresses use another internet gateway than everyone - i mean only traffic destined to internet should be redirected, destined to local networks - should not.

In Cisco world it works this way: access list ->  access list bounded to route-map with next hop -> route map applied to an interface.

In Dell it works with redirect lists, it looks like this:

! setting next-hop, source and destination
ip redirect-list INTERNET-OUT
 redirect

! redirect list applied to an interface
interface vlan 10
 ip redirect-group INTERNET-OUT


Works great, but there is a problem: how to exclude subnets: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and permit all other traffic? In Cisco I would create an ACL with three "deny" statement and "permit any" at the end, then bound ACL to route map and apply route map to interface.

As far as I found out Dell's redirect list does not support "deny" or something statements, I can only use "permit" or "redirect". Of course I can use only "redirect" statement and create something like that:

ip redirect-list INTERNET-OUT
 redirect 10.5.1.1 ip host 192.168.5.10 0.0.0.0 /5
 redirect 10.5.1.1 ip host 192.168.5.10 8.0.0.0 /7
 redirect 10.5.1.1 ip host 192.168.5.10 11.0.0.0 /8
 redirect 10.5.1.1 ip host 192.168.5.10 12.0.0.0 /6
 redirect 10.5.1.1 ip host 192.168.5.10 16.0.0.0 /4
 redirect 10.5.1.1 ip host 192.168.5.10 32.0.0.0 /3
 redirect 10.5.1.1 ip host 192.168.5.10 64.0.0.0 /2
 redirect 10.5.1.1 ip host 192.168.5.10 128.0.0.0 /3
 redirect 10.5.1.1 ip host 192.168.5.10 160.0.0.0 /5
 redirect 10.5.1.1 ip host 192.168.5.10 168.0.0.0 /6
 redirect 10.5.1.1 ip host 192.168.5.10 172.0.0.0 /12
 redirect 10.5.1.1 ip host 192.168.5.10 172.32.0.0 /11
 redirect 10.5.1.1 ip host 192.168.5.10 172.64.0.0 /10
 redirect 10.5.1.1 ip host 192.168.5.10 172.128.0.0 /9
 redirect 10.5.1.1 ip host 192.168.5.10 173.0.0.0 /8
 redirect 10.5.1.1 ip host 192.168.5.10 174.0.0.0 /7
 redirect 10.5.1.1 ip host 192.168.5.10 176.0.0.0 /4
 redirect 10.5.1.1 ip host 192.168.5.10 192.0.0.0 /9
 redirect 10.5.1.1 ip host 192.168.5.10 192.128.0.0 /11
 redirect 10.5.1.1 ip host 192.168.5.10 192.160.0.0 /13
 redirect 10.5.1.1 ip host 192.168.5.10 192.169.0.0 /16
 redirect 10.5.1.1 ip host 192.168.5.10 192.170.0.0 /15
 redirect 10.5.1.1 ip host 192.168.5.10 192.172.0.0 /14
 redirect 10.5.1.1 ip host 192.168.5.10 192.176.0.0 /12
 redirect 10.5.1.1 ip host 192.168.5.10 192.192.0.0 /10
 redirect 10.5.1.1 ip host 192.168.5.10 193.0.0.0 /8
 redirect 10.5.1.1 ip host 192.168.5.10 194.0.0.0 /7
 redirect 10.5.1.1 ip host 192.168.5.10 196.0.0.0 /6
 redirect 10.5.1.1 ip host 192.168.5.10 200.0.0.0 /5
 redirect 10.5.1.1 ip host 192.168.5.10 208.0.0.0 /4
 redirect 10.5.1.1 ip host 192.168.5.10 224.0.0.0 /3

But it seems to be little crazy :)
Is possible to make that easier way?

5 Practitioner

 • 

274.2K Posts

January 4th, 2018 05:00

I don't know that there is any other way of achieving this within the PBR. What about doing an IP ACL that is implemented on the physical interface that connects to 10.5.1.1? You could permit the sumbnets that are configured in the PBR, and then deny all other subnets.

No Events found!

Top