cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1767
Views
30
Helpful
23
Replies

PBR seems to be not implemented

robad
Level 1
Level 1

Hi Guys, It's probably going to be long, but it's something that is very important for my team.

We are working in company in few Lab's environment that is connected to IT.

Our Gateway for all labs is currently 2 old 6500 working with VSS.

Each lab is connected to the 6500, and each lab have is own gateway to IT, I mean that for each lab, there are 2 links from our Gateway to IT Gateways. Now we are working with

route-maps

 

We should start use 2 9600 instead of the 6500. right now we got only 1 9600, so we have time to test it. we have 2 unused labs that we can 'play' with and check the configs.

I'll tell you what we are trying to do, and please, let me know if it should work like that, and also, if you think you have some better way - we'll glad to hear.

 

The 9600 is : 9606R

Version : (CAT9K_IOSXE), Version 17.3.4

ACLs & Route-maps :


 

 

 

 

Extended IP access list A-to-B
10 permit ip 43.43.43.0 0.0.0.255 40.40.40.0 0.0.0.255
Extended IP access list A-to-any
10 permit ip 43.43.43.0 0.0.0.255 any

Extended IP access list B-to-A
10 permit ip 40.40.40.0 0.0.0.255 43.43.43.0 0.0.0.255
Extended IP access list B-to-any
10 permit ip 40.40.40.0 0.0.0.255 any

route-map A sequence 5
match ip add A-to-B
set ip next-hop 40.40.40.1

route-map A sequence 10
match ip add A-to-any
set ip next-hop [IT uplink address]


route-map B sequence 5
match ip add B-to-A
set ip next-hop 43.43.43.1

route-map B sequence 10
match ip add B-to-any
set ip next-hop [IT uplink address]

 

 

 

 

 

 The strange thing that is for example the Group B to any is working, because I can ping 8.8.8.8 for example, and then move the

ip policy route-map

command from the int vlan, it's not working. so the

route-map 

is working [at least for 'outside']

 

Pings between Group A to Group B not working....

It might be something with directly connected route or something, but I'm not sure...

Please advise . Thanks in advance

1 Accepted Solution

Accepted Solutions

you dont mention me so I dont see your reply until now.
you config is excellent except some point 
in Core SW you need only one VLAN for example VLAN 100
you all VLAN in trunk between access SW and Core
you need to add VLAN 100 to access SW also.
Now do routing policy or doing static route toward the SVI of VLAN 100 in core
and that it.

one more point
please select different VLAN number in both Access SW I see VLAN 20 in both Acces SW that wrong.

View solution in original post

23 Replies 23

ACL from A to B then you select

next hop

as one IP of B ?
can you draw network here.

Hi MHM, and thanks for you reply.

 

Yes, if the packet sent from A to B, I want the packet to go to Group B "Gateway".

 

I've added my design on the topic as attachment. can you see it ?

so the Box is L3SW, 
you have three L3SW 
between the L3SW there is PO L3 and you config PBR under it ?
is that your network ?

isse vlan 22.png

No need PBR 
there are two Access SW, 
each Access SW is the GW for client <in case you add more VLAN in feature> by config SVI in access SW
the Access SW to Core SW you will

config Access or trunk <allow VLAN>



in Core SW we will config SVI for same VLAN 
in Access SW we will config 

ip route 0.0.0.0 0.0.0.0 SVI <of Core SW>



this what will give us 
if the client want to connect to each other and SVI in access SW then they use SVI in Access SW
if the client in different Access SW want to connect then they will send traffic to Core and in core since there are SVI f each VLAN of Access SW then the Core will forward traffic to Access SW.

check this solution 

robad
Level 1
Level 1

9600-design-lab.PNG

robad
Level 1
Level 1

yes this is my network

but, I've tried it also without PBR, and pings between hosts from Group A to Group B didn't worked...

Let me check again and share the results

Thanks for the great reply

ping from Group-A to Group-B


first

IP routing

must config in Access SW
second default route toward the Core SW SVI need to add in Access SW.

Hi, 

The command

ip routing

was missing ! and now it's working

 

But, my goal is [for some reason] to use

Route-Map 

between my labs . [I'll have some more subnets under each Group, and some more groups]

A

route-map 

should work ? [I mean how/can I make it "win" the routing table]

I have one solution so another lab need I will share here soon.

hjhjhjhjhjhjhjhjhj.png

Hi, and thanks for your great willing to assist.

I understand your topology, but what will be the

route-map & access-lists

on on the "Core" switch that connected to IT ?

 

I'll tell you what, until now, in our current 6500 design, we are working like this :

current-design.PNG

 

I've draw only one lab. we have few labs like this.

each labs have few subnets/vlans, and at the end, only 1 vlan is getting up to the 9600. and then the

default-gateway

for all the "Group-A" vlans is the "Group-A" Gateway. it's working great for us until now, and for some reason it's not working in the 9600, and I suspected it;s something related to the device itself, or the IOS [Amsterdam version]. 

We should be able to work like this ?

 

Sorry for getting things more and more complicated  

Hello
Not sure what you are trying to accomplish, looks  both L3 SVi on the same device (9300) so intervlan communication will work anyway without policing routing 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Hi Paul, 

What the previous network engineer tried to achieve with the policy between labs, is that if a user from let's say Group-A will plug in his device and will configure some IP ike 10.x.x.x or 192.x.x.x, or any other IP that is not from our lab's subnets, he won't be able to communicate with any lab.

And that's why [he told me] he did the policy route also between labs. in order that only packets from the "allowed" subnets will be able to communicate. 

Hope it's helping

Hello


@robad wrote:

Hi Paul, 

What the previous network engineer tried to achieve with the policy between labs, is that if a user from let's say Group-A will plug in his device and will configure some IP ike 10.x.x.x or 192.x.x.x, or any other IP that is not from our lab's subnets, he won't be able to communicate with any lab.

And that's why [he told me] he did the policy route also between labs. in order that only packets from the "allowed" subnets will be able to communicate. 


If a user in pluging into network group x he should be using an ip addreess from within that subnet and no some random address that isnt even assigned to the network estate.


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul
Review Cisco Networking for a $25 gift card