cannot ping loopback - revisited

[ArchiTech89]

I don't really understand why the answer to the question worked before, but I have an almost identical problem. Here's the old discussion:
https://supportforums.cisco.com/discussion/11563226/cannot-ping-loopback

I can't ping the loopback on a Catalyst 2960.

I have a VLAN 33 on a 10.0.33.0 subnet. This is being routed over an 881 using an SVI (with 10.0.33.1) on the back side. I looked for the pings in Wireshark, but to my surprise they didn't exist! Then I captured again to see why I missed them, and subsequently discovered that the ARPs aren't being replied to by the loopback.

But this I don't think I understand. If the loopback IP address in on the same subnet as that assigned to the VLAN on the port coming into the switch, wouldn't it just switch the traffic over to the loopback interface? Why won't it answer the ARP request?

So then the other problem will be... If I don't use the same subnet for the loopback, how do I manage the switch via telnet/ssh over the network? It seemed like according to the other discussion, there would have to be some kind of other subnet for the loopback interface than what was already being advertised by the router for the VLAN SVI -- do I get that correctly?

Any ideas?

[Peter Paluch]

Jeremy,

You did not explain what is the IP address of the loopback on your Catalyst 2960 but I assume that it is in a different subnet than 10.0.33.0/24 (just as it should be).

In that case, you have to understand that each loopback interface is a separate, standalone and different network interface (even though a virtual interface) from all other interface on the device. If you want to reach this loopback from your VLAN 33, you must have routing activated on the switch. As suprising as it may sound, this is exactly what you need - you are in a particular network (10.0.33.0/24 for example) and you want to reach a destination that is outside that network. Routing is the only function that can accomplish that.

This is the reason loopback interfaces do not make much sense on Layer2 switches and on limited-feature Layer3 switches. These switches are incapable of routing whatsoever, or they have no way of advertising their loopback interfaces in a routing protocol. This makes the loopback interfaces effectively unreachable.

To access and manage switches remotely, the primary concept of IP connectivity is the management VLAN which is an arbitrary VLAN that is created, active, allowed on at least one switchport (access or trunk), and has its interface Vlan created, configured with an IP address and activated. This management VLAN is assumed to span your entire switched network and have all switches assigned to it. Therefore, any router that advertises this network provides a routed connectivity to it. Very often, there are no access ports configured for this VLAN, i.e. there is no end host directly connected to the management VLAN. Instead, remote management is performed from hosts in other VLANs, and on the router doing the inter-VLAN routing, an ACL is used to limit who can access devices in the management VLAN. As the router is the only place how stations in other VLANs can reach the management VLAN, it is very simple to control the access effectively.

Would this explain the issue?

Best regards,
Peter

[ArchiTech89]

Peter,

No, I actually had the loopback interface set for 10.0.33.254 -- the last device on the same class-C level subnet (the mask is 24 bits) as the client doing the pinging. Clearly that was wrong.

So I sure am grateful for this explanation. But then, if I do want to create a management VLAN for the express purpose of being able to manage the L2 devices via telnet/ssh, they need to have an IP address and that needs to be on the loopback interface, right? So do I then

1. Just set up a new SVI on the router,
2. give it an IP address and assign it to the new management VLAN,
3. make sure it rolls across the trunk (that the VLAN is configured on both sides -- the L2 switch side and the router side), and then
4. assign the loopback on the switch an IP address in that VLAN?

lol. This was all so much clearer in the CCNP labs during the classes I took. Is there a good resource I can use to understand how to set up/perpetuate management VLANs in the real world?

Thanks again, Peter (or anyone else) for any help you might be able to offer...

Cheers

[Peter Paluch · Accepted solution]

Jeremy,

But then, if I do want to create a management VLAN for the express purpose of being able to manage the L2 devices via telnet/ssh, they need to have an IP address and that needs to be on the loopback interface, right?

No. The address will be assigned to the interface Vlan you create for the particular management VLAN. Assume 4 switches in your network, connected together via trunks. Let's say you have decided to have VLAN 1000 as your management VLAN. So each of your switches would then be configured as follows:

vlan 1000
 name Management
!
interface Vlan1
 shutdown
!
interface Vlan1000
 ip address 10.255.255.<SwitchNumber> 255.255.255.0
 no shutdown
!
ip default-gateway 10.255.255.254

This simple example assumes that all switches are already connected together via trunks so that VLAN 1000 can span all of them. Then, the interface Vlan (SVI) for VLAN 1 is shutdown, as the VLAN 1 is not going to be your management VLAN anymore, and instead, a SVI for VLAN 1000 is created and an IP address is assigned to it. Finally, each switch has its default gateway out of its management VLAN configured - assuming the router that also must be connected to the VLAN 1000 has its IP address 10.255.255.254.

As you your numbered sequence:

1. Correct.
2. Correct; be aware that you do not assign SVIs to VLANs. SVI is by its very definition associated with its (and only its) VLAN; e.g. interface Vlan 123 is automatically associated with VLAN 123 and can never, ever, be associated with any other VLAN
3. Correct.
4. Incorrect. Once the SVI has its IP address assigned, why would you want to put the address on some other interface? Loopback interfaces are mostly usable on routers which have many IP addresses so that the loopback interface can be used as a single IP for the entire router. However, Layer2 switches normally have only one IP address and that one is already enough for management purposes. There is no benefit gained by using loopback interfaces on Layer2 switches.

Regarding reading about management VLANs - I suppose that googling for it will produce myriads of results. Check out this one, for example:

http://www.freeccnaworkbook.com/workbooks/ccna/configuring-a-management-vlan-interface

Best regards,
Peter

[ArchiTech89]

I get it now! I thought one could only create an SVI on multilayer switches. I was actually wondering why the ip address command was available under interfaces vlan 33 or whatever on my layer 2 2960. Now I understand that that's how to manage the switch!

I ended up doing the following:

• I created a new "management VLAN" number xx.
• I assigned one of the ports on the 2960 to that VLAN (even though I know I don't have to do that, it ended up working better for me because I'm dual homing my machine right now) and plugged my workstation into that port.
• I manually changed the static IP address of my management workstation's ethernet connection (the other is WLAN) to coincide with the management VLAN's subnet.
• I went into configuration mode, changed over to the VLAN interface, then assigned an ip address.

Now the VLAN SVI is the only interface on the 2960 switch that has an IP address. I can ping it and connect to it via telnet/ssh. And the other VLANs are accessible as well.

I only have one question/problem left... Should I disable the default management VLAN 1? If so, do I just do a shutdown on that interface? (I'm using another dummy VLAN for all unused ports and nothing is pointing to VLAN 1.)

And what about designating native VLANs? Is that part of creating/maintaining a management VLAN?

Yeah, I don't actually "google" things -- I "bing" 'em. I don't care much for Google's intrusive policies and I'm actually a bit frightened of them. And I did see that article, but it wasn't helpful in developing an overall understanding of the theory of and methods for implementing a workable management VLAN strategy -- at least from what I saw. But thanks anyway. I was actually hoping you knew of a resource that might be clearer/more in-depth.

No worries, though. You've been a big help already!