Download als PDF FileEin leidiges Thema! Wir haben vor einiger Zeit einen unserer Kunden von Cisco Catalyst 6500 auf Nexus 7000 migriert. Zum Einsatz kamen Sub2 mit Fab2 Modulen:
Mod Ports Module-Type Model Status --- ----- ----------------------------------- ------------------ ---------- 1 0 Supervisor module-2 N7K-SUP2 active * 3 48 1/10 Gbps Ethernet Module N7K-F248XP-25 ok 4 48 1/10 Gbps Ethernet Module N7K-F248XP-25 ok Xbar Ports Module-Type Model Status --- ----- ----------------------------------- ------------------ ---------- 1 0 Fabric Module 2 N7K-C7009-FAB-2 ok 2 0 Fabric Module 2 N7K-C7009-FAB-2 ok 3 0 Fabric Module 2 N7K-C7009-FAB-2 ok
Auf das Design möchte ich nicht weiter eingehen, so wie mans halt macht. 4 VDC’s (Core, Dist1, Dist2, DC)
Fast schon selbsterklärend, sind auf diversen SVI’s DHCP Relay’s eingerichtet:
interface Vlan241 ip address x.x.x.x x.x.x.x . ip dhcp relay address x.x.x.x ip dhcp relay address x.x.x.x
Da der Kunde sich mit dem redisgn eine teuere Netflow Appliance angeschaft hat, wollten wir diese natürlich auch ordentlich mit Flows versorgen:
flow exporter CA-NETFLOWCOLLECTOR destination x.x.x.x source loopback0 version 9 sampler PACKETWOLF mode 1 out-of 100 flow monitor MONITOR-INTERVLAN-TRAFFIC record netflow-original exporter CA-NETFLOWCOLLECTOR interface Vlan241 ip flow monitor MONITOR-INTERVLAN-TRAFFIC input sampler PACKETWOLF
Hier kam bereits die erste Ernüchterung, aufgrund einer Limitation der F2 Fabrics, kann nur ein sampled netflow konfiguriert werden, dh. 1 out of 100. Nun gut, 1/100 ist ja schon mal besser als gar nix und in der Summe schon ganz ordentlich!
Also hopp rein damit:
(config-if)# ip flow monitor MONITOR-INTERVLAN-TRAFFIC input sampler PACKETWOLF
An additional 1:100 sampler, over the configured sampler is applicable for F2 ports
uhh? auf einen 1/100 sampler nochmals einen 1/100 oder wie jetzt? Das wäre ja dann 1 out of 10’000. Das hingegen ist dann doch schon wenig!
Leider funktionierte nach der Umstellung DHCP-Relay überhaupt nicht, nach kurzem Tshoot und einer Neukonfiguration, sind wir auf folgende Fehlermeldung gestossen:
(config-if)# ip flow monitor MONITOR-INTERVLAN-TRAFFIC input sampler PACKETWOLF An additional 1:100 sampler, over the configured sampler is applicable for F2 ports Verify failed - Client 0x82000146, Reason: Tcam Allocation Failure, : DHCP, Netflow Sampler (SVI), Interface: Vlan241 Verify failed - Client 0x83000146, Reason: Tcam Allocation Failure, : DHCP, Netflow Sampler (SVI), Interface: Vlan241
Tatsächlich, schaut man sich die Internal ACL’s an, scheint es so als würde das Feature „DHCP Relay“ auf einer Art VACL aufgebaut sein:
show system internal access-list vlan 241
slot 3
=======
Policies in ingress direction:
Policy type Policy Id Policy name
------------------------------------------------------------
DHCP 4 Relay
Netflow profiles in ingress direction:
TCAM Class Profile Flow Monitor
---------------------------------------
INSTANCE 0x8
---------------
Tcam 1 resource usage:
----------------------
Label_b = 0x201
Bank 0
------
IPv4 Class
Policies: DHCP(Relay) [Merged]
Netflow profile: 0
Netflow deny profile: 0
5 tcam entries
0 l4 protocol cam entries
0 mac etype/proto cam entries
0 lous
0 tcp flags table entries
1 adjacency entries
INSTANCE 0xa
---------------
Tcam 1 resource usage:
----------------------
Label_b = 0x201
Bank 0
------
IPv4 Class
Policies: DHCP(Relay) [Merged]
Netflow profile: 0
Netflow deny profile: 0
5 tcam entries
0 l4 protocol cam entries
0 mac etype/proto cam entries
0 lous
0 tcp flags table entries
1 adjacency entries
INSTANCE 0xb
---------------
Tcam 1 resource usage:
----------------------
Label_b = 0x201
Bank 0
------
IPv4 Class
Policies: DHCP(Relay) [Merged]
Netflow profile: 0
Netflow deny profile: 0
5 tcam entries
0 l4 protocol cam entries
0 mac etype/proto cam entries
0 lous
0 tcp flags table entries
1 adjacency entries
No egress policies
Netflow profiles in egress direction:
TCAM Class Profile Flow Monitor
---------------------------------------
slot 4
=======
Policies in ingress direction:
Policy type Policy Id Policy name
------------------------------------------------------------
DHCP 4 Relay
Netflow profiles in ingress direction:
TCAM Class Profile Flow Monitor
---------------------------------------
INSTANCE 0x8
---------------
Tcam 1 resource usage:
----------------------
Label_b = 0x201
Bank 0
------
IPv4 Class
Policies: DHCP(Relay) [Merged]
Netflow profile: 0
Netflow deny profile: 0
5 tcam entries
0 l4 protocol cam entries
0 mac etype/proto cam entries
0 lous
0 tcp flags table entries
1 adjacency entries
No egress policies
Netflow profiles in egress direction:
TCAM Class Profile Flow Monitor
Und tatsächlich, Cisco hierzu:
On the Nexus 7000 we use an VACL to redirect all DHCP broadcast traffic to the CPU when the DHCP relay function is implemented. When this redirect occurs the Nexus 7000 does NOT broadcast these DHCP broadcast packets to all ports within the VLAN as one would expect. This is done based on the fact that it is believed that if a DHCP relay agent is configured, than the DHCP server does not exist on the local vlan and there is no need to broadcast this traffic locally.
Konkret heisst da nun auch, dass man auf dem SVI wo sich der DHCP selbst befinden, ebenfalls DHCP Relay konfigurieren muss. „GOOD2KNOW“
Jedoch „BACK2TOPIC“
Netflow liess sich nicht parallel zu DHCP Relay aktivieren. Zu diesem Zeitpunkt war genau gar nichts auf Google oder cisco.com zu dieser Limitation zu finden. Ok das ist der Punkt wo man den TAC einschaltet, schliesslich zahlt man ja die teuren Smartnet’s nicht umsonst!
Und tatsächlich, durch den TAC erfuhren wir von einem Bug der noch nicht Public war: https://tools.cisco.com/bugsearch/bug/CSCtf36357
n7k: Need ability to configure ingress netflow sampling with dhcp relay CSCtf36357 Description A Nexus 7000 switch does not currently support having ingress netflow sampling and DHCP relay configured on the same interface. We need this restriction removed. Symptom: When trying to configure the two features together you might see error message similar to: %$ VDC-1 %$ %NFM-2-VERIFY_FAIL: Verify failed - Client 0x87000146, Reason: feature combination is not supported in tcam, Interface: Vlan601 Verify failed - Client 0x83000146, Reason: feature combination is not supported in tcam, Interface: Vlan601 Conditions: none Workaround: When you remove the ip monitor netflow input, you need to bounce the l3 interface to take a effect. Fix is available in 6.2(2)
Fixed in Release 6.2(2) wurde am 6. Januar hinzugefügt. Der Kunde fährt allerdings 6.1.x. Nun klingt im ersten Moment nach einer Lösung
Leider ist der Sprung von 6.1 auf 6.2 ist nicht ganz trivial, da beim Upgrade jegliche Komponenten Upgrade werden.. Fabrics, Linecards etc. Des Weiteren muss die Supervisor über 8Gig Ram verfügen, dh man müsste ggf. ein RAM Upgrade machen. Zudem ist Hinzu kommt, dass man von dem Maintrain abweicht.. neuer ist nicht immer besser!
Cisco’s aussage hierzu ganz klar:
Beachten sollte man auch, dass von einem Sprung von 6.1.x auf 6.2.x kein ISSU möglich ist –> Downtime!
Der Kunde hat zum Glück auch eingesehen, dass so ein „Experiment“ mit einem Brandneuem Release wenig Sinn macht. Zurecht!
Wenige Wochen später wurde der Bug Report aktuallisiert:
26.01.2014 13:15 (als Antwort auf: awatson20) Hi Guys, The fix was planned originally for 6.2.2 but was pushed to 6.2.6 due some other priorities. This has been fixed in 6.2.6. Please see the release notes. http://www.cisco.com/en/US/docs/switches/datacenter/sw/6_x/nx-os/release/notes/62_nx-os_release_note.html#wp648748 Cheers, -amit singh
Schwache Leistung Cisco!
Den TAC bzw. Supportcase kann man übrigens hier mitverfolgen:
https://supportforums.cisco.com/thread/2213109
