Escape from Vlan. Bug Hack ?! Feature ... Or about the benefits of reading documentation
Good day, colleagues.
Again, I am risking ogresti minuses for captaincy, but I still find the info below useful. In the end, captaincy is not the lowest level. To say truisms, you need to at least know them. And if in everyday life and within the framework of banal erudition, it can be anyone except for children of very young preschool age (autumn will come in summer), then in the field of vocational education, we still need to grow. So the gurus under the cat can not watch. Well, if you just have fun, you can ...
')
I had to observe your picture once, which made him feel that very thing - even the captaincy does not shine, for nothing is incomprehensible.
It took one custom, long-unused link to hang one tricky device. The inheritance of the affairs of bygone days - the lack of documentation, any marks on the sockets and all that, well, you understand. No problem. Let's connect the device, look at the fdb in the kernel for the mac-address, find the access switch, look at it with the same fdb, define the port and configure everything as necessary. Mac is known, the device is connected, the traffic for the learning device will provide exactly and it needs to “reach” to the core - we are looking.
In the core (catalyst 35xx)
sh mac address-table | i xxxx.xxxx.xxxx
But the strange thing is, the mac glows in several Vlans at once with a plus to the one in which it should. Yes, they are really tagged on the device, but the port on the access switch (AT-85xx) is configured as untagged. And as tagged it is not included in any Vlan. The author intuitively (and very vainly, manuals should be read!) Expected from such a “clean” untagged port behavior similar to that in cisco, when
switchport mode access
switchport access vlan xxx
But, as I have already noted - in vain. Further investigations with a test machine showed that tagged traffic to untagged port is quietly received (if there is an appropriate. Vlan and switch, essno) and forwards (back there is no ess).
Having brought a static record for a certain IP from the manager Vlan to the arp-table on the test machine and lifting it to the network one as a tagged one was able to calmly float there with something more than arp requests. This is bad.
The situation is clarified manual. It turns out that this is a completely normal switch behavior that can be disabled by the command
set switch infiltering = yes
True, it was written in the manual (if I did not misunderstand) that, by default, this command exists and the behavior observed in practice should be disabled. But not the point. By the way, through the web-gui team is not available (here it is, the cause of ignorance).
And as it turned out, the real default setting of the switch is more compliant with the 802.1Q standard than the information about the default value of the parameter from the manual.
standards.ieee.org/getieee802/download/802.1Q-2005.pdf
c. 48
8.6.2 Ingress
Enable Portal Ingress Filtering Parameter. If this parameter is set. Disable Ingress Filtering, for all Ports. Any Port that supports setting this parameter also support resetting it. Clause 12.
Again, I am risking ogresti minuses for captaincy, but I still find the info below useful. In the end, captaincy is not the lowest level. To say truisms, you need to at least know them. And if in everyday life and within the framework of banal erudition, it can be anyone except for children of very young preschool age (autumn will come in summer), then in the field of vocational education, we still need to grow. So the gurus under the cat can not watch. Well, if you just have fun, you can ...
')
I had to observe your picture once, which made him feel that very thing - even the captaincy does not shine, for nothing is incomprehensible.
It took one custom, long-unused link to hang one tricky device. The inheritance of the affairs of bygone days - the lack of documentation, any marks on the sockets and all that, well, you understand. No problem. Let's connect the device, look at the fdb in the kernel for the mac-address, find the access switch, look at it with the same fdb, define the port and configure everything as necessary. Mac is known, the device is connected, the traffic for the learning device will provide exactly and it needs to “reach” to the core - we are looking.
In the core (catalyst 35xx)
sh mac address-table | i xxxx.xxxx.xxxx
But the strange thing is, the mac glows in several Vlans at once with a plus to the one in which it should. Yes, they are really tagged on the device, but the port on the access switch (AT-85xx) is configured as untagged. And as tagged it is not included in any Vlan. The author intuitively (and very vainly, manuals should be read!) Expected from such a “clean” untagged port behavior similar to that in cisco, when
switchport mode access
switchport access vlan xxx
But, as I have already noted - in vain. Further investigations with a test machine showed that tagged traffic to untagged port is quietly received (if there is an appropriate. Vlan and switch, essno) and forwards (back there is no ess).
Having brought a static record for a certain IP from the manager Vlan to the arp-table on the test machine and lifting it to the network one as a tagged one was able to calmly float there with something more than arp requests. This is bad.
The situation is clarified manual. It turns out that this is a completely normal switch behavior that can be disabled by the command
set switch infiltering = yes
True, it was written in the manual (if I did not misunderstand) that, by default, this command exists and the behavior observed in practice should be disabled. But not the point. By the way, through the web-gui team is not available (here it is, the cause of ignorance).
And as it turned out, the real default setting of the switch is more compliant with the 802.1Q standard than the information about the default value of the parameter from the manual.
standards.ieee.org/getieee802/download/802.1Q-2005.pdf
c. 48
8.6.2 Ingress
Enable Portal Ingress Filtering Parameter. If this parameter is set. Disable Ingress Filtering, for all Ports. Any Port that supports setting this parameter also support resetting it. Clause 12.
Source: https://habr.com/ru/post/148511/
All Articles