So I’ve come across a bug that is currently plaguing the environment I’m working within. While we have had plans to move away from VTP and phase for a routed design, it was one of those legacy implementations that unfortunately no one wanted to give up for quite some time. So thus, VTP was implemented with our Nexus 7ks due to the fact that ever sinceĀ 5.1(1) it was supposedly supported. We’ve found quite an odd issue however that TAC has still yet to conclusively nail down. The jest is that on most trunks, VTP pruning shows that it is functioning but is actually not being filtered in hardware on the Nexus 7k.
If you issue show int trunk for example you can see that for Eth1/16 it is only forwarding the following vlans (We have 154 vlans by the way, remember that number for reference a bit later):
N7010# show int trunk
...
...
--------------------------------------------------------------------------------
Port Vlans in spanning tree forwarding state and not pruned
--------------------------------------------------------------------------------
Eth1/16 1,33,64,764
So lets get on the linecard and determine what its actually doing…
N7010# attach module 1
Attaching to module 1 ...
To exit type 'exit', to abort type '$.'
module-1#
module-1# show hardware internal ashburton port 16 cbl egress
CBL: Egress
VLANs on CBL state ASHBURTON_CBL_PORT_DISABLED(0):
0, 3, 7 - 9, 11, 13, 17, 19, 21, 23, 25 - 32, 35, 37, 39, 41, 43, 45, 49, 51 - 53, 55, 57, 59, 61, 63, 65, 67, 69, 71, 73, 75, 77, 79, 81 - 87, 89, 91, 93 - 97, 100 - 111, 113 - 114, 116 - 117, 120 - 131, 134 - 159, 164, 166, 168, 170 - 171, 173 - 218, 220 - 232, 234 - 239, 242, 244 - 255, 258 - 312, 316 - 350, 356 - 357, 374 - 447, 451 - 499, 502 - 505, 508 - 509, 512 - 591, 593 - 595, 597 - 665, 667 - 701, 703 - 705, 707 - 709, 711, 713 - 715, 717, 719, 721, 723, 725 - 732, 734 - 735, 737, 739 - 741, 743, 745, 747, 749, 751 - 753, 755, 757, 759, 761, 763, 765, 767, 769, 771, 773, 775, 777, 779, 781 - 787, 789, 791, 793 - 797, 800 - 811, 813 - 818, 820 - 887, 889 - 940, 945, 955 - 998, 1000 - 4095,
3942 VLANs in ASHBURTON_CBL_PORT_DISABLED(0) state.
0 VLANs in ASHBURTON_CBL_PORT_BLOCKED_LISTENING(1) state.
0 VLANs in ASHBURTON_CBL_PORT_LEARNING(2) state.
VLANs on CBL state ASHBURTON_CBL_PORT_FORWARDING(3):
1 - 2, 4 - 6, 10, 12, 14 - 16, 18, 20, 22, 24, 33 - 34, 36, 38, 40, 42, 44, 46 - 48, 50, 54, 56, 58, 60, 62, 64, 66, 68, 70, 72, 74, 76, 78, 80, 88, 90, 92, 98 - 99, 112, 115, 118 - 119, 132 - 133, 160 - 163, 165, 167, 169, 172, 219, 233, 240 - 241, 243, 256 - 257, 313 - 315, 351 - 355, 358 - 373, 448 - 450, 500 - 501, 506 - 507, 510 - 511, 592, 596, 666, 702, 706, 710, 712, 716, 718, 720, 722, 724, 733, 736, 738, 742, 744, 746, 748, 750, 754, 756, 758, 760, 762, 764, 766, 768, 770, 772, 774, 776, 778, 780, 788, 790, 792, 798 - 799, 812, 819, 888, 941 - 944, 946 - 954, 999,
154 VLANs in ASHBURTON_CBL_PORT_FORWARDING(3) state.
module-1#
I should note, the ashburton is an ethernet media controller on these N7K-M132XP-12L linecards that handles all the logical configuration checks of the interfaces in hardware… including obviously, wether or not to drop frames destined to certain VLANs when egressing or ingressing the port.
Whats important here is that there are 154 VLANs in ASHBURTON_CBL_PORT_FORWARDING state.. which should not be the case per cisco TAC.
The end result is unknown unicasts and broadcasts are literally being on all of those vlans to the edge switching which is leading to CAM saturation on our 3750-X platforms…
Yet another reason NOT TO USE VTP… *sigh*
Follow Me!