07-13-2022 04:35 AM - last edited on 07-26-2022 10:14 PM by Translator
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
Solved! Go to Solution.
07-19-2022 05:03 AM
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.
07-13-2022 05:33 AM - last edited on 07-26-2022 10:15 PM by Translator
ACL from A to B then you select
next hop
as one IP of B ?
can you draw network here.
07-13-2022 06:42 AM
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 ?
07-13-2022 07:00 AM
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 ?
07-13-2022 07:37 AM - last edited on 07-26-2022 10:23 PM by Translator
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
07-13-2022 08:15 AM
07-13-2022 08:16 AM
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
07-13-2022 08:25 AM - last edited on 07-26-2022 10:25 PM by Translator
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.
07-14-2022 02:00 AM - last edited on 07-26-2022 10:26 PM by Translator
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]
07-14-2022 04:43 AM
I have one solution so another lab need I will share here soon.
07-14-2022 06:30 AM
07-17-2022 12:35 AM - last edited on 07-26-2022 10:28 PM by Translator
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 :
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
07-17-2022 03:55 AM
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
07-17-2022 04:38 AM
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
07-17-2022 05:59 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide