Nexus 7k DHCP Relay + Netflow limitation

Ein 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

 

 

 

 

Samuel Heinrich
Senior Network Engineer at Alpiq Intec (Basel, Switzerland)
Arbeitet in Raum Basel (Switzerland) als Senior Network Engineer mit über 10 Jahren Erfahrung im Bereich Netzwerk und Telekommunikation.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.