cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2386
Views
0
Helpful
18
Replies

Routing over switchport but within VLAN/VRF

Steve Prescott
Level 1
Level 1

I currently have the topology as per the diagram below on the ‘Internal’ side.

ScreenShot084.bmp

There is OSPF/BGP between the two cores.

VTP is used to ensure all the necessary VLANs are propagated to the edge switches.

I now have the requirement to connect one of the edge switchports to an external link so that clients on the external side of the link (192.168.118.0/24) can access a web server connected to CORE-01 as shown (10.122.10.2).

The question is how do I achieve this?  I obviously need the route adding into the VLAN5 VRF, but where do I point it to and how do I point it down g1/0/19 on the edge switch? How will traffic coming into g1/0/19 on the edge switch know to be in VLAN 5 ?

I know I need to add access-lists somewhere too.

Any advice would be very warmly welcomed.

18 Replies 18

Jon Marshall
Hall of Fame
Hall of Fame

Steve

Are the core switches doing all the inter vlan routing ?

Is the edge switch doing any routing at all or is it just a L2 switch ?

If it just L2 then what vlans are on it and does this mean the links between the core switches and the edage switch are L2 trunks.

Is the link between the edge switch and the external switch going to be used purely for this web server access ?

Do you only want access to be allowed to the web server ie. nothing else in vlan 5 ?

You can use static routes to go to and from a VRF but we need to understand how this is currently setup

Jon

Hi Jon.

My apologies - I was trying to keep it as concise as possible but have obviously missed some inportant information

The Core switches are doing VLAN routing with the VRF's

The edge switch is a 3750X with an ipbase license. It is currently operating at L2 though.

The links from the cores to the edge switch are trunks.

I run VTP across the site.

Yes, the link from the edge switch to the external site is purely to give them access to the Web server (There are goo reasons why it has to be done this way!)

Yes, all I want clients at the external site to access is the web server, nothing else in that VLAN.

Hope that provides some clarity.

Steve

No problem.

If the edge switch is L2 only then whatever you do you are going to have to extend a vlan to the client switch. This is not necessarily a very good idea because of the STP complications of having a shared vlan under different adminstrative control. You would most definitely need to use BPDU Guard on the edge switch port to the client switch as you must make sure that there switch cannot become root for that vlan.

Bear in mind also that any broadcasts etc. in that vlan on the client side goes all the way to your core switches.

So assuming you cannot bring then in on a L3 link then i can see a few options -

1) allocate the edge switch port connecting to the client into vlan 5. Then use a VACL to control access so they can only get to the web server.

I mention it for completeness but if this is a server vlan then all of the above applies only more so. The only advantage to this is you do not need routes on the core switches to get to and from the VRF. But i don't personally think it is worth the risk especially as the client may be able to see traffic they shouldn't.

2) create a new vlan and SVI purely for this connection. Only the trunk links, the edge switch port connecting to the client switch and the client switch port are in this vlan. Note also if the client switch is L3 capable the other end could be a L3 routed port.

Then use an acl on the SVI to control access to and from the VRF. You would need a host route for the web server to get to the VRF and a route in the VRF to get back to the clients subnet.

3) a hybrid of the two is to create the new vlan as in 2) but place the SVI into the same VRF as vlan 5. This way you do not need routes to and from the VRF on the core switches. Some of the dangers mentioned in 1) are mitigated ie. broadcasts from the client switch etc. are not going to affect vlan 5.

You could then use an SVI acl to control traffic between the vlans even though they were in the same VRF because the traffic still needs to be routed from the new vlan to the existing vlan.

Of the options i would say definitely not 1). As i say i only mentioned it for completeness.

2) and 3) both have pros and cons.  With 2) you have complete separation from the VRF until they get to the core switch and there you have strict control in terms of both the acl and the routes you will have to add for the client to be able to get to the web server.

With 3) as soon as they enter your network they are in the right VRF but they still have to route to vlan 5 so you control access with the SVI acl on the new vlan.

What do you think ?

Jon

Hi Jon,

I beleive the edge switch should be capable of routing - would that produce a better solution?

The VLAN is a CCTV VLAN and will hence have alot of multicast traffic, although the core switches are configured as igmp snooping queriers and there is no multicast routing outside of the VLAN.

Steve

Steve

It depends on how much extra configuration and disruption you want.

If you made the connection to the client a L3 routed port then you are not extending a vlan out to another client which is good. But you would then need on your edge switch -

1) a L3 routed port for the client connection

and

2) an SVI for a vlan to route to and from the L3 routed port.

I dont't think with IP Base that VRF-Lite is supported so you would have to control access to and from the VRF on the core switch which may not be a bad thing. It would mean using routes to get to and from the VRF.

It really is up to you as i don't know what your security requirements are, how much you trust the client, what the client setup is etc.

Jon

That sounds like a much better solution.

I assume its something like this then...

EDGE

int gn/n/n

no switchport

ip address 10.122.77.1 255.255.255.252    (Their end would be 10.122.77.2 and they add a route to 10.122.10.2 over this link)

ip access-group 100 in

ip access-group 101 out

access-list 100 permit tcp 192.168.118.0 0.0.0.255 10.122.10.2 eq 443

access-list 100 deny esp any any

access-list 100 deny ip any any

access-list 101 permit tcp 10.122.10.2 eq 443 192.168.118.0 0.0.0.255

access-list 101 deny esp any any

access-list 101 deny ip any any

ip route 192.168.118.0 255.255.255.0 10.122.77.1

COREs

Add a static route in vrf VLAN5 to point 192.168.118.0 to 10.122.77.1

but how to I then add a route pointing 10.122.77.1 to the edge switch - make the target the management address of the edge switch (which that VRF can currently see)?

I'm not quite sure why I need an SVI for a vlan to route to and from the L3 routed port??

Steve

You need an SVI on the edge switch because the edge switch is now routing ie it routes between subnets. But if you only have one L3 interface it has nothing to route onto ie.

traffic arrives on the L3 port from the client. The edge switch does a route lookup and sees it is meant for vlan 5. So it looks in it's routing table. But it only has one route ie. the directly connected L3 interface IP subnet.

You could add a static route but you need a next hop and so the edge switch needs an interface in the same IP subnet as the next hop so thats why you need another L3 interface on the edge switch.

Which SVI you add to the edge switch is up to you. It could be another SVI for vlan 5 and you could route between them there but as the IP Base does not support VRF-Lite i doubt you will be able to add static VRF routes.

So because VRF-Lite is not supported with IP Base you need to have a new vlan with an SVI on both the edge and core switch and you route to the core switch via that.

I don't know because i can't test but if you didn't want to add routes to and from the VRF on the core switch you may be able to place the core switch SVI end in the same VRF as vlan 5. The edge switch SVI is not in the VRF because you can't use VRFs on the edge switch but you are still controlling access with the acl on the routed port.

Like i say this should work and would mean no additional routes on the core but i can't say for sure and you may want to control access to and from the VRF on the core switches with routes.

Jon

Thanks for taking the time to explain Jon, much appreciated.

I am now off till next Monday, so will sit down and look at this closely then and see what solution I end up with

Thanks again,

Steve

Steve

No problem.

If you have any other queries etc. then please feel free to come back.

Jon

I certainly will.  Just read your NetPro interview btw, very intersting read and good to get an insight into people's background and how they arrived here.

Hi Jon,

I think I have gotten my head round this now with your help.

If I am correct, the required config is going to be something like this...

EDGE

Ip routing

Int gn/n/n

desc L3 link to external site

No switchport

Ip address 10.122.50.1 255.255.255.248                      (10.122.50.2/29 at other[external] end)

Ip access-group 101 in

Ip access-group 102 out

Int vlan5

desc For routing purposes to external site

Ip address 10.122.11.251 255.255.254.0

Int vlan 50

Ip addr 10.122.50.6 255.255.255.248

Ip route 192.168.118.0 255.255.255.0 10.122.50.2 

Access-list 101 permit tcp 192.168.118.0 0.255.255.255 10.122.10.2 eq 443

Access-list 101 deny ip any any

Access-list 101 deny esp any any

Access-list 102 permit tcp 10.122.10.2 eq 443 192.168.118.0 0.255.255.255

Access-list 102 deny ip any any

Access-list 102 deny esp any any

CORE

int vlan50

ip vrf forwarding VLAN5

ip addr 10.122.50.5 255.255.255.248

ip route vrf VLAN5 192.168.118.0 255.255.255.0 10.122.50.6

I am not in a position to test it at the moment, but would appreciate if you could give it the thumbs up or otherwise.

Once again, many thanks

Steve

Jon Marshall
Hall of Fame
Hall of Fame

Steve

I had a think about this over the weekend and i'm not sure this is the best way to do it. The issue is -

1) traffic from external client gets to edge switch and is routed onto vlan 5. It is sent straight to the web server

2) the web server then sends the return traffic to the SVI on your core switch because that is it's default gateway.

3) the core switch then has to route the traffic back out of the same SVI (vlan 5) to get to the edge switch

What may be a better solution is -

1) use a new vlan for connectivity between the edge switch and the core switch

2) create an SVI for that new vlan on both the edge switch and the core switch

3) then either -

a) place the new SVI on the core switch into the same VRF so you would not need routes on the edge switch for the vlan 5 IP subnet nor would you have to add routes to and from the VRF on the core switch.

You would need a route in the new vlan for the client network so it would need adding to the VRF

or

b) don't place the new SVI on the core switch into the same VRF and add routes to and from the VRF.

i think either woud be better because traffic to and from the web server has to go via the core switch.

Jon

Hi Jon,

Thanks for the reply, but I must say I am getting a bit confused now,

Are we now saying...

On edge, have SVI for the L3 link, and an SVI in new vlan for link between core-edge.

On core, have SVI in new vlan for link between core-edge in same vrf as vlan5.  Need to add route in vrf VLAN5 to external client subnet, pointing to core-edge SVI on edge switch.  Edge then needs ip route to client subnet pointing to external end of the L3 link?

I think I would better understand if you could post a sample config of what you are getting at if that is at all possible. It may become clearer for me then.  I am assuming that the ACL's are going onto the ingress/egress point, ie. the L3 interface on the edge switch?

Steve

Apologies for confusing the issue.

My concern was traffic going straight to vlan 5 from the edge switch but then return traffic goes back to the SVI for vlan 5 on the core because that is the default gateway for the web server. So then the traffic has to go back out of the SVI for vlan 5 and sometimes this doesn't work too well.

So this is what i was proposing -

1) use a L3 routed port on the edge switch to connect to the client switch and filter traffic with an acl as you have done.

2) create a new vlan for use between the edge switch and the core switches

3) create an SVI for this vlan on both the edge switch and the core switches

4) put the SVI on the core switches into the same VRF as vlan 5

5) if you are not going to be running a routing protocol between the core switches and the edge switch you will need -

a) a route on the edge switch for the web server IP  pointing to the core switches new vlan SVI IP address. Note if you run HSRP between the core switches then point the route to th HSRP VIP

and

b) a route on the core switches for the client subnet pointing to the new SVI IP address on the edge switch.

It's not that different to what you posted other than you are using a new vlan to commmunicate between the edge and core switches. This ensures that traffic to and from the web server goes vlan the core switches.

Does that make more sense ?

Jon

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco