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

Data, Voice and Management Vlans are able to talk to each other

Mark Thattazhi
Level 1
Level 1

Hi Community,

I have a question, i would like to know if it is recommended for the Data, Voice and Management vlans in the same environment can talk between each other. 

I noticed this issue in my network. Like for example, i`m able to ping a cisco ip-phone(connected in voice vlan) from my PC(connected in a data vlan). I do not know whether its a usual situation that takes place.

Please let me know if this scenario is normal to work in this manner. If not, i can explain our network configuration to provide more insight on this issue.

Thank you.

1 Accepted Solution

Accepted Solutions

Okay I notice you say it is shown as an OSPF route and not a directly connected route which I think explains it.

If the SVIs are in VRFs then if you do a "sh ip ro vrf <VRF name>" you should see them as directly connected routes but in the global routing table you are seeing them as OSPF routes.

I think what is happening is you are learning these routes via the outside interfaces which are not in VRFs ie. vlans 1501 and 2501 in your example.

So when you ping from a client in a data vlan to a client in a voice vlan on the same switch you are not going direct between SVIs because these are in different VRFs.

You are going out through the FWSM and then back in again ie. data to voice would be -

specific data vlan -> MSFC ->  vlan 1500 -> FWSM -> vlan 1501 -> MSFC ->  vlan 2501 -> FWSM -> vlan 2500 -> MSFC -> specific voice vlan

where I am assuming only vlans 1501 and 2501 are not in VRFs ?

If that's the case then you are using VRFs on each switch to segregate the traffic and then using the FWSM to control what is allowed between the VRFs.

To check if the above is right what is the next hop IP of the routes for IP subnets that are local to the switch and in VRFs ?

I would expect the next hops in the global routing table to be the SVI IPs for vlans 1501 or 2501.

Is this what you see ?

Jon

View solution in original post

18 Replies 18

Mark Malone
VIP Alumni
VIP Alumni

Hi yes generally vlans will be allowed talk to each other unless theres a specific security risk with that vlan and you do not want to have it communicating with other networks or maybe it belongs to another company and you don't want them having ip reachability to your devices. At the end of the day there all still in the same data plane anyway on the same device.

But in most standard networks the security part is taken care of by the firewalls/ips/ids etc rather than locking down individual SVIs from what I have seen anyway other users may see it differently

 

 

Hi Mark Malone,

Thank you for your reply.

I would like to explain the issue here. Our data, voice, cctv and management vlans are in seperate VRFs. But an ip-add from any of these vlans are reachable among themselves. And all ip-add or SVIs configured in seperate VRFs can be seen in the global routing table as well as in the routing table of the VRFs.

Is there something wrong in this or is this the way how it works?

I wouldnt say there is anything wrong with that, you have the option to allow vrfs speak to each other or not to speak to each other

usually with VRFs the whole point is to isolate networks from being able to speak to each other like an ISP PE router as in that case you definitely would not want to be leaking VRFs between customers but vrfs can be configured to allow them share the routes between them as well and can be quite useful in certain scenarios when maintained by one company

It really depends on your security requirements of what you allow them do and who speaks to who

I understand. So, if it was allowed for vrfs to share routes between them, What will be the configuration ? And, how can that be done.

I couldn`t find any configuration for sharing these vrf routes in our Cat6500 distribution. Even if it was configured i do not know how the configuration will look like or where will it be applied.

Thank you. 

Hi with vrfs you could leak the tables using route-targets under the vrf statements , here is a good link that gives a brief explanation of the concept and what the config would look like

http://packetlife.net/blog/2013/jun/10/route-distinguishers-and-route-targets/

 

http://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/multiprotocol-label-switching-vpns-mpls-vpns/47807-routeleaking.html

Thanks for the document links. There is no RD or route-targets configured in the distribution switch. So, i guess that's not the reason for the leak.

I would like to clarify something that i came across and find it doubtful that this might be the reason for vrf leak.

We have two distributions (Dist-1 and Dist-2) connect through a core switch (Core-1).

Dist-01 has the following Vlans:

Data - Vlan 101, 102, 103,104 and Vlan 1500 (inside SVI for data)- all in data-vrf.

Voice- Vlan 201, 202, 203, 204 and Vlan 2500 (inside SVI for voice)- all in voice-vrf.

Vrf-lite has been configured for both data and voice

Data-vrf and Voice-vrf.

Two SVIs, Vlan 1501 (outside SVI for data) and Vlan 2501 (outside SVI for voice) are configured.

These two vlans (1501 and 2501) are routed using ospf in the global routing.

In FWSM, a context has been create dist-01.cfg

vlan 1500 (inside-data) and vlan 1501 (outside-data) has been bridge using bridge group 10.

vlan 2500(inside-voice) and vlan 2501(outside-voice) has been bridge using bridge group 20. 

Same configurations has been done in dist-02 for another group of vlan-ids.

And these two distributions are connected to core through a tengig link. These link interfaces are routed using ospf also.

Will the bridge-group be a reason for these vrf to leak as the outside interface (Vlan1501 and Vlan2501) are routed in global routing.

 

 

I wouldn't have though bridge groups would cause vrf leaking , where the vrf lite is configured is there shared RTs set

Do you mean route-targets(RTs) ? No.

Where are you seeing the routes in the global routing table ie. is it on the distribution switches and the core switch or just the core switch ?

Jon

Hi Jon,

I'm able to see all the routes in global routing table and all the vrf routing table in both the distributions and global routing table in core (there are no vrfs in core).

My data and voice vlans configured in a particular distribution is shown as an ospf route in the global routing table.

For example:- If there is a data vlan- 102 and a voice vlan 202 in dist-01,forwarded to their respective vrfs data-vrf and voice-vrf is shown as an ospf route in the global routing table of that distribution(dist-01) and as an ospf IA route in the other distribution(dist-02) and in core switches global routing table.

Okay I notice you say it is shown as an OSPF route and not a directly connected route which I think explains it.

If the SVIs are in VRFs then if you do a "sh ip ro vrf <VRF name>" you should see them as directly connected routes but in the global routing table you are seeing them as OSPF routes.

I think what is happening is you are learning these routes via the outside interfaces which are not in VRFs ie. vlans 1501 and 2501 in your example.

So when you ping from a client in a data vlan to a client in a voice vlan on the same switch you are not going direct between SVIs because these are in different VRFs.

You are going out through the FWSM and then back in again ie. data to voice would be -

specific data vlan -> MSFC ->  vlan 1500 -> FWSM -> vlan 1501 -> MSFC ->  vlan 2501 -> FWSM -> vlan 2500 -> MSFC -> specific voice vlan

where I am assuming only vlans 1501 and 2501 are not in VRFs ?

If that's the case then you are using VRFs on each switch to segregate the traffic and then using the FWSM to control what is allowed between the VRFs.

To check if the above is right what is the next hop IP of the routes for IP subnets that are local to the switch and in VRFs ?

I would expect the next hops in the global routing table to be the SVI IPs for vlans 1501 or 2501.

Is this what you see ?

Jon

Mark Thattazhi
Level 1
Level 1

Yes Jon,

You`re right. The routes for ip subnets in a vrf is show like this in the global routing table:

O 10.201.2.0/24 [110/20] via 10.201.248.2, 1:16:12, Vlan 1501

where 10.201.2.0/24 is a data vlan and 10.201.248.2 is vlan1500.

So, how do I block communication between the data and management vlans ? Should i apply an acl in fwsm ? Is that the correct method ?

Even my traceroute from one vrf to another gives me a request time-out. Let say if i traceroute from data network to voice ip-add, it just shows me the 1st and the last hop. So, i believe traceroute is also being blocked by the fwsm. Am I right ?

To control traffic you need to use the FWSM by the looks of it.

So you need to get onto that and see what rules are currently being used.

There is no other way because even within the same switch traffic must go out and back in via the FWSM and it certainly does to other vlans on the other distribution switch.

Which makes sense otherwise there is not a lot of point to using VRFs in the first place.

Jon

 

OK Jon, Thank you for the info. This makes sense to me know.

Review Cisco Networking products for a $25 gift card