Nexus Data Broker (NDB) Configuration

[charlesleggett]

Good morning all,

I am getting started using a Nexus Data Broker (and Cisco in general), so please take it easy on me.

I cannot figure out how to get the NDB to pass traffic.

I believe that I have the Configured Ports, Monitoring Devices, Configure Filters, and Apply Filters sections configured correctly in the Web GUI.

I think that my problem lies in the configuration of the underlying ports.

I've tried setting them in switchport modes of: access, trunk, and monitor.

I've tried to tag them with no vlans and with all vlans.

The only way that it will pass traffic is in trunk mode with all vlans tagged.

In this mode of course, it is simply passing all traffic and the filters that I have configured in the WebGUI have no effect.

Any ideas? Help me out.

Thanks.

--

Charles H. Leggett

[branfarm1]

Any luck on this?  I'm just getting started with NDB and am also running into problems. The documentation seems pretty thin on this.

[charlesleggett]

Thanks to one of the Cisco guys, I've learned how to get things working. Let me know if you're still having trouble after you read this post, and I'll get you in touch with the right guy.

However during this effort, I learned something that I didn't expect: any one packet has one and only one "path" through the NDB. I expected the NDB to replicate packets so that they could be sent to more than one connection, which may each contain multiple ports.

Anyway, with that caveat out of the way, here's what we did together to get NDB running with an embeded controller on our Nexus 3500 series. I'm skipping the installation, which is pretty straight forward and starting with configuration.  Use this along with the install guides carefully b/c settings (pipeline speciffically) are different on different series.

Setup physical switch:

configure terminal

hardware profile forwarding-mode openflow-hybrid

     show hardware profile forwarding-mode

spanning-tree mode mst

     show spanning-tree

vlan 1-4094

     show vlan

interface ethernet 1/1-48

switchport mode trunk

     show interface ethernet 1/1-48 brief

spaning-tree port type edge trunk

mac-learn disable

hardware profile tcam region vacl 0

hardware profile tcam region racl 0

hardware profile tcam region ifacl 1024 double-wide

Setup virtual switch:

openflow

switch 1

default-miss cascade drop

pipeline 203

controller ipv4 <your IP> port 6653 vrf management security none

of-port interface ethernet1/1-48

Configure in Management GUI:

Devices > Nodes Learned > Node (right-click) > Operation Mode > Proactive Forwarding

<username> > Management > Flows > Add flow entry > Add a DROP filter (priority 2, with no other filter criteria)

[branfarm1]

Thanks, Charles.  I was missing a couple of key elements so I'm a little further a long now.

Did you have any problems configuring connections?  I've got one setup right now to match all traffic on a few ingress ports, and send to an output port to one of my sniffer boxes, and that's working, but I"m also seeing the same data being sent out ports that are not configured as ingress or egress for a connection.

Also, that caveat is pretty huge -- after all, the datasheet for NDB clearly states:

Traffic replication and forwarding

●  You can aggregate traffic from multiple input tap and SPAN ports that can be spread across multiple Cisco Nexus switches. ●  You can configure the software to replicate and forward traffic to multiple monitoring tools that can be connected across multiple Cisco Nexus switches. ●  This solution is the only solution that supports any-to-many forwarding across a topology.

Did your Cisco contact say if that was a temporary issue?

[charlesleggett]

The thing that fixed that for me was the very last line above:

1) Click on your username in the top right

2) Click Management

3) Click Flows

4) Click Add flow entry

5) Add a DROP filter

      a) Set the priority to 2

      b) Leave everything else default

[branfarm1]

What version are you on?  I'm on 2.2 and it looks like they've added that drop rule by default now, along with two others:

__Catch-ALL Drop__ (Priority 0, all else default, action DROP)

__Punt ARP__ (Priority 1, Ethernet type 0x806, action CONTROLLER)

__Punt LLDP__ (Priority 1, Ethernet type 0x88cc, action CONTROLLER)

[charlesleggett]

Sorry, I guess that I should have mentioned that the existing DROP rule for whatever reason doesn't work.

You can leave all of those in place and add another DROP as I described earlier.

Try that and I bet that you'll stop seeing the same data being sent out on other ports as you described above.

[branfarm1]

Well I gave that a try but still no luck.  I'll have to open a case and see what happens.

Thanks for all your help!

[Kevin McCabe]

All,

Just to clarify here, any one packet, on ingress, once it matches a flow (or in NXAPI mode, a line in the ACL) it performs that action and does not continue down the logic path. I'll try and illustrate this:

If you switch has the following flows:

Rule 1 - Priority 10 : IP traffic ingressing e1/1 should output e1/10

Rule 2 - Priority 5 : IP traffic ingressing e1/1 should output e1/20

No traffic will ever match rule 2, because it's priority is less than rule 1 and matches the same traffic.  With Nexus Data Broker you can do traffic replication, you can specify for any "connection" multiple egressing interfaces.  On the switch you would see something like:

Rule 1 - Priority 10: IP traffic ingressing e1/1 should output both e1/10 and e1/20

In the above circumstance you would see matched traffic replicate and egress both e1/10 as well as e1/20.

This is all expected behavior and currently how Nexus Data Broker is intended to work. We are evaluating how the product could work from a technical perspective if we were to pass the packet on to evaluate other flows.

This is most impactful when our customers use drop filters. The common misconception is that a drop filter would allow a lesser priority connection to evaluate the packet. In reality, when a packet hits a match on a drop flow, the packet is intentionally dropped.

As a result we have opened CSCux29175 which would allow for an "Exclude Filter" in certain circumstances.

I hope this was helpful.

[branfarm1]

Thanks, Kevin - that's helpful to know.

[dmooregfb]

Charles, can you put me in touch with your cisco connection on this? I am working with a 3172PQ and having some issues too.

Thanks,

Dave

[Kevin McCabe]

Charles,

To document what branfarm1 's fix was: we ended up upgrading from 6.0(2)A7(1) to 6.0(2)A6(5). While I know we went from the A7 to A6 train, A6(5) had some fixes in the openflow code that have not yet been ported to other lines of code for the 3548s.

If you're having issues and have a valid smartnet contract, feel free to open a TAC case and we can take a look.  If you're looking for help on the support forums side of things, it may be better to start a new thread since this one was about 3548's flooding traffic. (note: moving to  6.0(2)A6(5) also partially resolved the flooding issue, and a workaround was to install a manual flow to drop the traffic).

Kevin