SRX

Hi,

This is an add on to a previous SNMP issue.

As the SRX I am using is ALL VR related then there is no default context as such. All the physical interfaces and logical tunnel interfaces belong to a VR on the system. This means also that there is no inet.0..... 

With regards to SNMP, I have managed to get information out of the system via PRTG that relates to the particular context. So, for example, the main context is Customer-VR and everything else connects to that context. I use that context for SNMP and what comes back is the LT interfaces and contexts, but that is it. Nothing else.

I still cannot get the ACTUAL CPU, RAM etc.... core information....... It always seems to read from the context no matter what I try.....

Any ideas on how to read the CPU and the RAM please?

Hello,

In JUNOS, getting OIDs that are related to master|global|default routing-instance via custom VR|VRF is not supported with SNMPv3.

And all RE CPU/memory/temperature, linecard CPU/memory/temperature etc OIDs are related to master|global|default routing-instance.

HTH

Thx

Alex

Hi Alex,

That is not good if that is the case.

That is actually a little worrying. Is there no way around this issue please? 

We do, infact, use SNMPv3 and VRs for security..... 

Hello,

---

@adgwytc wrote:

. Is there no way around this issue please? 

 

We do, infact, use SNMPv3 and VRs for security..... 

---

If You establish LT between Your "receiving" VR for SNMPV3 packets and GRT/inet.0, then it will work.

The "context" field in the SNMPv3 packets must match the routing-instance name where these packets are processed/examined/ingested by JUNOS' snmpd.

HTH

Thx

Alex

Hi Alex,

"If You establish LT between Your "receiving" VR for SNMPV3 packets and GRT/inet.0, then it will work.

The "context" field in the SNMPv3 packets must match the routing-instance name where these packets are processed/examined/ingested by JUNOS' snmpd."

The configuration I currently have already utilises the context, as shown below:

set snmp v3 vacm access group snmpgroup default-context-prefix security-model usm security-level authentication read-view allmibs
set snmp v3 vacm access group snmpgroup context-prefix ninegroup-radius security-model usm security-level authentication read-view allmibs
set snmp v3 vacm access group snmpgroup context-prefix Customer-VR security-model usm security-level authentication read-view allmibs

set snmp routing-instance-access

So, the SNMP setting is there.

What's the best way for configuring an LT between the Customer-VR and the default RT (inet.0) please?

I ask this because I have no interfaces in any default at all, so I am not sure where to link the LT to?

Cheers

Hello,

---

@adgwytc wrote:

Hi Alex,

  

The configuration I currently have already utilises the context, as shown below:

set snmp v3 vacm access group snmpgroup default-context-prefix security-model usm security-level authentication read-view allmibs

---

The SNMP GET with this context will be answered only if it is received in GRT/inet.0.

---

@adgwytc wrote:

set snmp v3 vacm access group snmpgroup context-prefix ninegroup-radius security-model usm security-level authentication read-view allmibs

---

 The SNMP GET with this context will be answered only if it is received in routing-instance "ninegroup-radius".

Etc etc

---

@adgwytc wrote:

 

 

What's the best way for configuring an LT between the Customer-VR and the default RT (inet.0) please?

 

I ask this because I have no interfaces in any default at all, so I am not sure where to link the LT to?

 

 

---

 Please see below the sample config. If You don't include lt-0/0/0.123 into any VR, it will remain in the GRT/inet.0.

set interfaces lt-0/0/0 unit 123 encapsulation ethernet
set interfaces lt-0/0/0 unit 123 peer-unit 321
set interfaces lt-0/0/0 unit 123 family inet address 203.0.113.1/30
set interfaces lt-0/0/0 unit 321 encapsulation ethernet
set interfaces lt-0/0/0 unit 321 peer-unit 123
set interfaces lt-0/0/0 unit 321 family inet address 203.0.113.2/30
set routing-instances Customer-VR interface lt-0/0/0.321

On SRX, You also need to include LT interfaces into security zones + add policies.

On certain SRX models, or with SRX cluster where LT is not supported, Your only option is a cable loop - You can loop it from the unused revenue port to the fxp0. 

HTH

Thx

Alex 

Hi Alex,

"If You don't include lt-0/0/0.123 into any VR, it will remain in the GRT/inet.0"

That is fantastic. exactly what I wanted. No document I could find anywhere to state how to do that end of the link.... Now I know.... cool.

Yes, the rest of the config I know and utilise.... It's all good.

Absolutely brilliant. I'll configure it and give it a go..... see if it works on the SRX1500.

Thanks

Hi Alex,

That doesn't work.

Maybe I'm a little lost here, but I do not quite understand how I can just create an LT and leave it nowhere? How is anything meant to respond? 

I configured the 2 x LT interfaces and placed one in the Customer-VR amnd the Customer Zone and left the other. The Customer Zone is an "any any any permit"..... The only thing I can think of is that we should now, from prtg, use the new LT address that resides in the default? Is this correct?

If I set the prtg to auto-discover within the Customer-VR still, then it only sees the new LT interface and not the other end of the LT. Because there is nothing at the other end of the LT other than the second LT interface, then it does not respond to anything (because there is no routing anywhere)..... I tried placing a static route from the Customer-VR, but no luck...... 

Hello,

You need to address both ends of LT and point Your PRTG to the IP address @ LT end that is in GRT/inet.0.

The example config showing how to add IP address to LT is in my previous post.

You may need to add proper routing from PRTG to that IP address.

Include both LT ends in security zones  + add policies.

HTH

Thx

Alex

Hi Alex,

That is exactly what I thought. I have already configured everything.

The only part I have not completed is where to place the "default" end of the LT. What security zone? The same security zone (Customer-Network) as the other LT end?

So, as follows:

lt-0/0/0.20 ----  Customer-Network security zone

lt-0/0/0.21 ---- Customer-Network security zone

Or, should I just create a new security zone and pop it in there and then complete and "any any any permit " policy?

Hello,

---

@adgwytc wrote:

 

The only part I have not completed is where to place the "default" end of the LT. What security zone? The same security zone (Customer-Network) as the other LT end?

 

So, as follows:

lt-0/0/0.20 ----  Customer-Network security zone

lt-0/0/0.21 ---- Customer-Network security zone

 

Or, should I just create a new security zone and pop it in there and then complete and "any any any permit " policy?

---

 It depends on overall design, level of complexity You wish to tolerate during t'shooting and Your attitude towards risk.

Including both LT ends into the same security zone is enough but then make sure You have an intra-zone permit policy in place.

HTh

Thx
Alex

Hi Alex,

It's all good so far..... it is just the very last part causing the problem.....

First thing is, I cannot place both interfaces in the same security zone as it wants those interfaces in the same VR too. So, I have created a new security zone and placed lt-0/0/0.21 in there and also created an "any any any permit" policy. 

Now, here is where the problem will always exist.... I can ping LT-0/0/0.20 from the Probe, awesome. I cannot ping LT-0/0/0.21. The reason for this is surely because LT-0/0/0.21 does not exist in any VR and therefore does not know how to get back out via the Customer-VR. The only way around this that I can see is that I route leak between inet.0 and Customer-VR.inet.0?

What do you think?

Hi there,

---

@adgwytc wrote:

Hi Alex,

 

 

 

Now, here is where the problem will always exist.... I can ping LT-0/0/0.20 from the Probe, awesome. I cannot ping LT-0/0/0.21. The reason for this is surely because LT-0/0/0.21 does not exist in any VR and therefore does not know how to get back out via the Customer-VR. The only way around this that I can see is that I route leak between inet.0 and Customer-VR.inet.0?

 

What do you think?

---

 A static/32 route in GRT pointing back to Your NMS via LT IP@ in Customer-VR will solve Your problem.

Using addressing from my LT example config and assuming Your NMS is  at 198.51.100.1:

set routing-options static route 198.51.100.1/32 next-hop 203.0.113.2

HTH

Thx

Alex

Hi Alex,

Here is an update for everyone really with the configuration.

Firstly, as Alex pointed out, configure an LT from your entry VR to an end LT that exists only in a zone:

set interfaces lt-0/0/0 unit 20 description to-snmp-default
set interfaces lt-0/0/0 unit 20 encapsulation ethernet
set interfaces lt-0/0/0 unit 20 peer-unit 21
set interfaces lt-0/0/0 unit 20 family inet address x.x.x.x/30
set interfaces lt-0/0/0 unit 21 description to-snmp-customer
set interfaces lt-0/0/0 unit 21 encapsulation ethernet
set interfaces lt-0/0/0 unit 21 peer-unit 20
set interfaces lt-0/0/0 unit 21 family inet address x.x.x.x/30

So, place one of these LT interfaces into the SRX entry VR and the security zone(this is the VR that your SNMP server will access the SRX for polling). In my case "Customer-VR". 

set routing-instances Customer-VR interface lt-0/0/0.20

set security zones security-zone Customer-Network

Now, create a new zone for the peer LT interface:

set security zones security-zone snmp-test-lt host-inbound-traffic system-services all
set security zones security-zone snmp-test-lt host-inbound-traffic protocols all
set security zones security-zone snmp-test-lt interfaces lt-0/0/0.21

Create an intra-zone policy for this new zone. I just made an any any any permit. It's protected from external anyway.

Now all that is needed is the routing in place.... use the address of the SNMP server and use the LT-0/0/0.20 interface addrerss as the next-hop..... for example:

set routing-options static route 10.10.10.1/32 next-hop 192.168.10.1

10.10.10.1 = SNMP Server

192.168.10.1 = lt-0/0/0.20 address

Just make sure any other firewalls and systems in between have the routes and accessability in place.

I have configured the above and can now access all the default OIDs.

Thank you for your help Alex. Much appreciated

Can you try suggestions in KB27284 (How to pull SNMP v3 information from non-default routing-instance )

- https://kb.juniper.net/InfoCenter/index?page=content&id=KB27284&actp=search