SRX

Has anyone implemented SNMP via the fxp0 interface?

I just had a few concerns about it

- Which of the two fxp0 interface do you poll?

- If your SNMP server is off subnet from the fxp0 subnet that means that you need to properly route the servers /32 out the fxp0 interface which means that SNMP server can no longer be routed anywhere else and is not dedicated to monitoring fxp0 interfaces (not scalable)

-

Hello there,

---

@Magraw wrote:

Has anyone implemented SNMP via the fxp0 interface?

 

 

---

I did quite a few times, albeit on M/T/MX series, not SRX

---

@Magraw wrote:

 

- Which of the two fxp0 interface do you poll?

 

---

Both. This is the most reliable method of getting full and complete SNMP stats from the box as a whole, and I always used separate SNMP engine-ids on master RE and backup RE (and separate keys if SNMPv3 is used) in addition to sourcing SNMP traps/responses from fxp0 source IP, to make sure SNMP server properly recognises the SNMP data as either coming from master RE or backup RE.

---

@Magraw wrote:

 

- If your SNMP server is off subnet from the fxp0 subnet that means that you need to properly route the servers /32 out the fxp0 interface which means that SNMP server can no longer be routed anywhere else and is not dedicated to monitoring fxp0 interfaces (not scalable)

-

---

Not sure if I get what the actual issue is. if polling both REs, both REs must have (1) static /32 route(s) towards SNMP server(s) and (2) "set system backup-router <blah> destination <SNMP server /32>" defined (as many times as there are SNMP servers). (1) will be used by master RE and (2) will be used by backup RE.

If you are looking to use both out-of-band and in-band SNMP servers,then backup RE cannot be managed in-band.

You can use same prefixes for SNMP servers and for something else _provided_ "something else" resides in separate logical router or separate routing-instance.

HTH

Rgds
Alex 

Thanks for the reply.  Let me try to clear up my concerns with the last point:

-  If I have an SNMP server on a subnet (10.10.10.0/24) sending SNMP queries to my fxp0 interface (192.168.100.2) for example I have to configure the SRX to route the traffic to my SNMP server (10.10.10.5) via the fxp0 interface.

This would mean i would have a static route (10.10.10.5/32 next-hop 192.168.100.1) and a backup-router statement for 10.10.10.5/32 going to 192.168.100.1

This would work out great but what if this SNMP server is also used to monitor servers and other devices living throughout the network.  As soon as the SNMP tries to route across a Juniper device there will be issues because I have told the Juniper box to send all traffic bound for the SNMP server out the fxp0 interface ( Since its non-transit the traffic hits the floor).

This leads me to a case where my SNMP server can poll any Juniper Device with OOB ports (fxp0) but can't get anywhere else in the network.

the main table inet.0 in my case is being used for inter-datacenter connections so that SNMP server must use that table to route around the world. 

Am I euchered here?  I find it strange that Juniper would require you to leave inet.0 table compeltly void of all data traffic if anyone wants to fully use the OOB features.

Thanks!

Hello,

If you want your 192.168.100.2 router to be managed OOB but also route SNMP traffic for other nodes, using only 1 SNMP server 10.10.10.5, then it is still possible to achieve with FBF on 192.168.100.2 router.

But this 192.168.100.2 router must have 2 (or 3) interfaces to your 10.10.10.0/24 subnet: fxp0 (or 2*fxp0) and 1 PFE (sub)interface.

fxp0 (or 2*fxp0) will be used to forward SNMP from/to 192.168.100.2 box and 1 PFE (sub)interface will be used to forward SNMP from/to other devices.

With such setup, you have to devise a reliable protection for your 10.10.10.0/24 network from outside world.

A "chained" fxp0 setup where fxp0 on 192.168.100.2 router is plugged into your OOB network, and fxp0 of adjacent node is plugged into 192.168.100.2 router won't work, as you have already mentioned.

I would suggest to build a proper OOB network, connect fxp0/me0/vme0 of all JNPR devices to it and use it only for management traffic. It will save you time and $$$ in the long run and could be your savior in times of "all-out" emergency.

HTH

Rgds

Alex

We do have a fully OOB mgmt network.  All fxp0, me0 interfaces connect up to a seperate physical EX-4200.  I just still run into the routing issue with the SNMP server not being able to get routed across to a different datacentre or server since it must go through the core firewall which is a Juniper device with an fxp0 interface. 

How would FBF help me get the traffic to other devices?  This fxp port confuses me to no end.  I see the traffic as doing the following:

Sent Traffic path

Data goes out the normal path over the data network

SNMP Server  -------> Core Firewall -------> Some server

Reply traffic

The reply gets hijacked by the Juniper device beacause of the /32 routes I have.   The issue is that the core firewall will never pass this traffic because I would come in a revenue port (Data Plane) and need to go out the fxp port ( control plane)

Some Server -------> Core firewall -------OOB MGMT Switch --------> SNMP Server

Thanks for your time again, this is the most problamtic Juniper issue i have faced to date, understanding the best way to implement this port effectively.

Hello again,

From the Core firewall perspective, you are managing Core FW out-of-band but everything else in-band. If you could make it uniform, that would ease your pain a lot, but anyway:

Looking at forward traffic path

SNMP Server  -------> Core Firewall -------> Some server

Question #1: is the "SNMP server----->Core firewall" traffic arriving at Core firewall via PFE interface?

And looking at return path

Some Server -------> Core firewall -------OOB MGMT Switch --------> SNMP Server

 If the answer to Q1 is yes, then you could configure a FBF filter on Core firewall (either as interface filter or forwarding table filter) to forward the SNMP response+trap traffic out the same PFE interface where the SNMP requests came from.

 HTH

Rgds

Alex

I see, that does make sense.

As for your first point of making everything uniform, I wish I could.  How can I have all my network devices on one OOB network?  the devices live in different Datacenters and we have to manager other things such as VMWare hosts, Load balancers, DNS appliances.  I could see having all Datacentre specific things placed on the OOB magement network but devices that live in another DC MUST go through the Juniper device in order to go to another city (MPLS).

The other thing is if you put a server's vlan onto the OOB switch its not really seperated anymore, I now have data that would originate from the "production" path get routed over to the OOB so my SNMP server can see it.

I am open to hear how your best approach would be to implement this.  This is all fairly greenfield so we have the chance to do it right.

Thanks for all your help so far, its really helpfull!

Hello,

I think if you could afford to add a 2nd NIC to SNMP server, and make sure SNMP server uses different source IPs to communicate with Core FW _and_ with the rest of your network, that would solve all your problems.

See ASCII art in attachment.

HTH

Rgds

Alex

Attachment(s)

snmp_server_2NICs.txt   329 B 1 version

Since you would need a new routing-instance for FBF anyway it might be a little simpler to use the 2nd instance minus the FBF component. e.g. Fxp0 in inet.0 with it's existing route to the SNMP server but add new transit-traffic routing-instance (full Virtual Router type) - place all of your production traffic here, including a route through a transit port to the same SNMP server . No filtering involved.

Both the RE and your protected hosts will be able to communicate with the same server this way. I don't do this for SNMP but have succesfully for Syslog.

I heard that forwarding syslog out fxp0 was a bad idea since it should stream out the data plane and revenue port to now overwhelm the control plane

Hello there,

---

@Magraw wrote:

I heard that forwarding syslog out fxp0 was a bad idea since it should stream out the data plane and revenue port to now overwhelm the control plane

---

Syslog - maybe, depending on what do you want to syslog.

Direct SNMP polling of the forwarding plane as well as traps directly from the forwarding plane are not supported, on any JUNOS device.

HTH

Rgds

Alex

---

@Magraw wrote:

I heard that forwarding syslog out fxp0 was a bad idea since it should stream out the data plane and revenue port to now overwhelm the control plane

---

It depends on the logging load but generally yes it's a bad idea to attempt to stream through the RE. But for the SNMP traffic you listed originally it's not a factor, it's just a question of routing separation for the protected hosts/transit traffic vs. self to the same host, not that the data-plane would be handling any kind of SNMP service cals.