Header Only - DO NOT REMOVE - Extreme Networks

Purview appliance with more interfaces on different subnets


Userlevel 3
Hi, is possible to deploy the Pureview appliance with more interfaces on different subnets or under a NAT device respect the Pureview Sensor? In my scenario I've got a NAT device between my internal lan where I've got the ExtremeControl and the ExtremeAnalytics appliance (virtual) and the coreflow2 switch is on another subnet and I reach this throught the nat device. As test, I've natted 1-1 the Extreme Analytics Appliance and I've used the NAT IP address as the remote gre endpoint on the coreflow2 switch. In this test I see in the external interface of the nat\router the GRE packets, but nothing reach my internal Pureview appliance. How is possible to use Pureview in a deployment like that? Thanks

17 replies

Userlevel 3
Hi Antonio,

Maybe the Knowledge article below can be of help. It specifies NetSight, but it may be of use for Purview too if you have not already reviewed it.
How to setup NetSight to use multiple interfaces

Regards
Tony
Userlevel 3
Hi Tony, I've already seen the Knowledge article on Netsight with multiple nic, but it doesn't work for Purview...the configuration wizard don't permit to define different subnet masks (for example an ip with mask 16 on the first nic and and ip with mask 24 on the second nic....I don't know if this is possible changing manually the configuration files of the interfaces and if this works...).
In my case I'm trying to add a second NIC to the Netsight and connect one of them outside the nat device....that receive the flow from a purview applaince connected outside the nat device...
Userlevel 3
Can you please post a diagram of what you have currently and what you are trying to accomplish? Thanks.
Userlevel 3
Hi Matthew, I attach the diagram of what I want to do (a Purview on my demo network 192.168.10/24 natted 1-1 by a Windows 2012 R2 NAT Router device to ip 172.16.151.102 that is the end of the gre tunned with the Purview sensor (in my lab a SSA switch).
In this demo lab, I see that GRE packets on the external interface of the NAT-Router device, but nothing reach the internal Purview engine.
In my second test, I've add a Purview engine on network 172.29/16 and then I've added a second NIC to the NetSight VM with one NIC on my internal demo lab 192.168.10/24 and the second one attached to network 172.29/16.
I prefer the first schema with only one Purview engine natted 1-1 ....is this schema possible or I nee to put the external Purview engine?
In this second case, when I add the pureview sensor to NetSight (that in this case has a second NIC connected directly to the same network 172.29/16 of the sensor), the OneView interface says that the sensor is not completly reachable....but are on the saem subnet and there is no a firewall between them..

Userlevel 3
In your first test, this is expected. the GRE tunnel extends to the NAT device but then does not know what to do or where to go. If your NAT device supports GRE tunnels, then you need to create 2 tunnels, one between the SSA and the NAT device and then another one between the NAT device and Purview. you then need to ensure that traffic is forwarded across the GRE tunnels appropriately. If this is a linux device then you need to bridge the TUN interfaces. as for your second test, I have no idea on what you are trying to accomplish. you do not need to add a second NIC to Netsight. You have one of two choices: either add an additional interface on the purview engine and have that in your demo network (192.168.1.x) OR (and this is the better way) move the management of the SSA onto your 172.29 network and not worry about NAT at all. Simply add an additional VLAN to the SSA, put an interface on it (with management enabled) and use "no ipforwarding" now that interface will be a completely out-of-band interface and should be able to talk directly without having to deal with NAT.
Userlevel 3
I Matthew, thanks for your instructions. Regarding the first test, I use a Windows 2012 R2 server that act as NAT-Router device, so I need to check if is possoble to do as you suggest for this test (two gre tunnels). For the suggestion to move the management of the SSA switch to my demo networks, my company policy don't permit me to do that becasue in this manner I've got a switch device that bypass our internal firewalls. Yesy, ipforwarding is disabled between the VLANs, but the security administrators don't permit me to create a such schema. I'll try to extend the GRE tunnel as first demo. Thanks, Antonio
Userlevel 3
But the SSA does not have any connectivity between the networks. they don't allow any out of band management from network devices? Can you put another interface on the purview engine on the 192.168 network? that would be the easiest way to accomplish this. this way you can have one GRE tunnel between the SSA and the purview engine, and then everything from Netsight to the Purview engine is across a sepatate NIC/network. I don't think you can do the GRE tunnels on windows as a GRE proxy/forwarder... also you would need to change the GRE config in the purview engine as it is a separate tunnel coming from your windows box. otherwise i am not aware of a GRE tunnel being able to be forwarded across a windows NAT, where windows is not the endpoint.
Userlevel 3
In first case, where I move the SSA management on the 172.29/16 networks, I've got a switch that has one NIC (the one that receive the mirror traffic) on the internal LAN and the management NIC on the demo LAB, and I know that in this case is secure, but for our policy I need to pass from the internal firewall (someone has fair that if an hacker corrupt the switch can pass between the two networks without pass thought the firewall). Regardin add a second NIC to the purview engine, I can't because I've tried to do this, but I've got networks with different masks and the wizard on purview engine want that I use the same masks on all the interfaces...probally I need to configure this scenario in manual mode...
Userlevel 3
You should be able to accomplish this with option 3: Interface Tunnel Mirrored, and put that second interface on the 192.168 network. If you cannot set a different subnet mask this is a bug and should be followed up with GTAC. as a workaround you configure both this was for the same subnet mask and then later manually go back and change the mask in the system config files.
Userlevel 3
Thanks Matthew, I'll try do do as you suggest. Thanks
Userlevel 3
I forget to say before, that if I attach a pc to the same switch where is attached my ge.1.1 interface of the SSA sensor and I use a neflow packet version 9 generator, I see the packets on my Purview appliance... Seems that my SSA sensor don't send the netflow packets out...
Userlevel 3
Your eth0 address is 192.168.10.102, and your GRE tunnel is from the SSA to the purview appliance (not the post-NAT address), so I'm assuming the 192.168.1.x address.
also this would be the same destination interface that the netflow would go to.
Userlevel 3
In my case the gre tunnel is between SSA ip address 192.168.1.227 and the ip 172.29.151.102 that is the value assigned to the secondary NIC of my Purview appliance attached outside the NAT device, instead eth0 ip address is 192.168.10.102 and this interface is attached to a virtualswitch "inside" under the nat device. So now the gre tunnes is the red line in the picture below of the new schema

Userlevel 3
if you do successive show netflow statistics do you see the exported packets increase?
you can also try disabling the cache and re-enabling it.

Also your diagram says tg.1.2 is your mirror port but the config has ge.1.2...?
Userlevel 3
Hi Matthew, yes, my mirror port is ge.1.2, on the schema is writted an old interface...
Yes, the exported packets increase...


Then I've disabled and re-enabled the netflow cache, but seems that netflow udp packets on port destination 2055 don't reach the purview appliance....
Userlevel 3
Hi Matthew, I've removed the wrong default gateway entry in the SSA configuration: ip route 0.0.0.0/0 interface vlan.0.100 1 and now the netflow packets udp port 2055 arrive to the purview engine also on the external interface of the Purview VMs.. Regards, Antonio

Reply