02-18-2014 08:33 AM - edited 03-07-2019 06:16 PM
I currently have the topology as per the diagram below on the ‘Internal’ side.
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.
02-18-2014 10:23 AM
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
02-19-2014 03:23 AM
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.
02-19-2014 07:33 AM
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
02-19-2014 07:45 AM
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
02-19-2014 08:13 AM
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
02-19-2014 08:27 AM
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??
02-19-2014 08:45 AM
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
02-19-2014 08:50 AM
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
02-19-2014 08:57 AM
Steve
No problem.
If you have any other queries etc. then please feel free to come back.
Jon
02-19-2014 09:01 AM
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.
02-24-2014 07:27 AM
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
02-24-2014 10:42 AM
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
02-25-2014 12:41 AM
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?
02-25-2014 04:21 AM
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
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: