Quantcast
Channel: All SRX Services Gateway posts
Viewing all 17645 articles
Browse latest View live
↧

Re: J-Web Dashboard Widgets often don't load

October 29, 2019, 6:41 am
$
0
0

J-web has never been good on these platforms. In general I will not expect any fix in the 15.1X49 software train. I know Juniper is actively working on improving the J-Web experience and some improvements has been made in 19.3R1.

 

You can try to take 19.3R1 for a spin and see if it helps. If it does, then you need to validate if everything is still working in your setup with the new Junos version... and personally I would wait until the first service releases are out before putting it into production.

 

If possible, please reach out to your Juniper partner or account team and ask to get a proper J-web experience. The more who asks this, it's easier to prioritize internally at Juniper.

↧
Search

Re: SRX650 Upgrade Path

October 29, 2019, 6:42 am
$
0
0

HI Guys,

  I have a further question = if we set the local account password to 20 characters, will the TACACS credentials be affected and still operate at 9 chars?

 

Thanks

 

Paul

↧
↧

Re: On-box reporting error

October 29, 2019, 6:58 am
$
0
0

EMTSU,

 

Some of the SRX3XX devices have encountered disk access failures due overuse and this is why Juniper recommend the following software releases that include an important eUSB driver:

 

https://kb.juniper.net/InfoCenter/index?page=content&id=TSB17581

 

Devices at greater risk are those in environments that use increased disk operations including On-Box Logging, consistent trace-options, security logging to on-device files including session-logging. I looks like the message you reported has been integrated in newer Junos versions to raise awareness of this situation.

 

If you are not using that feature it will be advisable to delete that part of the configuration, it comes by default after 15.1X49-D100 onwards. Alternatively you can send logs to external syslog servers.

 

"The on-box reporting feature is enabled by default when you load the factory-default configurations on the SRX Series device with Junos OS Release 15.1X49-D100 or later."

 

Ref: https://www.juniper.net/documentation/en_US/junos/topics/concept/security-on-box-reporting-understanding.html

 

Hope this helps!

 

↧

Re: VLAN.IRB trunk issue in SRX340

October 29, 2019, 7:17 am
$
0
0

BenBen,

 

Based on your configuration I can see that your topology looks like this:

 

                             irb.737
HostA----Trunk----(ge-0/0/0)-SRX
                              |
			(ge-0/0/2)
			      |
			access port in vlan 737
			      |
			      |
			    HostB

 

Also I understand that you are trying to ping HostB (in above topology). If you run "show arp interface irb.737 no-resolve" and you see HostB's MAC address then the SRX should be generating a ping; it would be important to confirm if that ping is being received by HostB. Can you take a packet capture of HostB to confirm this situation? Can you plug a different device to that port and test the ping?

 

Also share the following command from the SRX when pinging hostB to confirm if a session is getting created:

 

> show security flow session protocol icmp destination-prefix [HostB_address]

 

 

Please also confirm that HostB is not expecting tagged packets. Note ge-0/0/2 is configure as an access port hence the packets will be sent untagged.

 

↧

Re: J-Web Dashboard Widgets often don't load

October 29, 2019, 7:14 am
$
0
0

Hi Jonas,

 

Thank you for taking the time to reply, I really appreciate it.

 

I have been following the JTAC recommended versions up until now and have noted the jump to Junos 18.2R3, but I'm (very) reluctant to make the move at the moment.

 

You have inspired me to write to our rep' at Juniper, but I'm sceptical how much difference it will make if any.

↧
↧

Re: J-Web Dashboard Widgets often don't load

October 29, 2019, 7:17 am
$
0
0
 wrote:

J-web has never been good on these platforms. 

 

Is it good on any platform?

↧

Re: On-box reporting error

October 29, 2019, 7:44 am
$
0
0

Thank Ipaniagua. Your reply is most helpful, thank you. 

 

The error I received actually prevented commit, so it would seem Juniper have taken a hard line on preventing the use of on-box reporting with newer firmware, which sends a clear, if worrying, message to users i.e. they are clearly concerned about the quality of the component used in earlier hardware revisions of the SRX300 series of devices.

↧

Re: On-box reporting error

October 29, 2019, 7:55 am
$
0
0

EMTSU,

 

Im glad the info was helpful, please mark the post as Resolved if you consider so. Regarding the logging, I will always suggest to to log any data to external servers rather than on-box.

 

↧
Search

Re: On-box reporting error

October 29, 2019, 7:55 am
$
0
0

Ipaniagua, one other thing!

 

I also have the following config. concerning logging on my devices:-

 

    syslog {
        user * {
            any emergency;
        }
        file messages {
            any notice;
            authorization info;         
        }
        file interactive-commands {
            interactive-commands any;
        }
        file kmd-logs {
            daemon info;
            match KMD;
        }
        file security {
            any any;
            match RT_FLOW_SESSION;
        }
    }

Will this generate files on-box too? Should I be concerned about any of the config. above relating to disk overuse?

↧
↧

Re: SRX 345 QinQ - 802.1ad

October 29, 2019, 8:00 am
$
0
0

Are you allowed to configure "vlan-id 100" (outer vlan id) under unit 20 on that interface?

 

I believe the problem is related to the SRX not knowing via which logical unit process those frames on.

 

↧

Re: VLAN.IRB trunk issue in SRX340

October 29, 2019, 8:07 am
$
0
0

Are these connectivity issues ocurring on this vlan only? Can you try using a vlan tag different than 737 for that subnet?

 

↧

Re: On-box reporting error

October 29, 2019, 8:20 am
$
0
0

I dont think you have to be concerned about them, they wont log as much data as on-box reporting.

 

The only ones I will suggest to log outside of the SRX will be the "RT_FLOW_SESSION" related logs, but only if you consider that the logging rate is quite high. First check with the following command if any data is getting logged:

 

> show log security

 

For data to be logged on that file two conditions have to be present.

 

1. "mode event" has to be configured under [edit security log] hierarchy

2. "log session-init" or "log session-close" has to be configured on your security-policies

 

 

↧

Re: SRX 345 QinQ - 802.1ad

October 29, 2019, 8:49 am
$
0
0

The configuration does not error out, let me run test and I will come back to you.

 

If that works it will be odd to explain why double 0x8100 tags work just fine.

↧
↧

SRX550M Upgrade Path

October 29, 2019, 9:24 am
$
0
0

Hello All,

 

Have a SRX550M currently running 15.1 that I'd like to get upgraded to the recommended version of 18.2.  Do I need to first jump to 17.4 

↧

Re: SRX 345 QinQ - 802.1ad

October 29, 2019, 9:34 am
$
0
0

Hi

 

Configuring vlan-id under unit 20 overwrites vlan-tags section, please have a look on interface config below.

 

 

root# show interfaces ge-0/0/0 
flexible-vlan-tagging;
gigether-options {
    ethernet-switch-profile {
        tag-protocol-id 0x88a8;
    }
}
unit 20 {
    vlan-id 100;
    family inet {
        address 10.10.1.122/24;
    }
}
↧
Search

Re: SRX 345 QinQ - 802.1ad

October 29, 2019, 9:37 am
$
0
0
 wrote:

Are you allowed to configure "vlan-id 100" (outer vlan id) under unit 20 on that interface?

 

I believe the problem is related to the SRX not knowing via which logical unit process those frames on.

 

Could this be on single direction only(ingress to SRX), let's remember,  when packets are originated from SRX tagging seems to be correct(please have a look in original pcap files).

↧

Re: SRX 345 QinQ - 802.1ad

October 29, 2019, 10:00 am
$
0
0
 wrote:

I may misinterpret the traces and what I see;   but it looks like the 802.1ad tags are somehow ignored by SRX kernel(or placed elsewhere), the main reason I say that is the look of pcap trace captured when SRX is originating traffic, we can see ARP request to L2 b.cast and the test server is replying to it, but the SRX kernel never sees reply.

 

I would also like; if possible to understand why  "tag-protocol-id 0x88a8" config line seems to be ignored; it makes no difference on QinQ tagging.

Well, if no volunteers;  I will do a bit of monologue.

I have found a potential reason as to why "tag-protocol-id" makes zero difference.

When I started to go thru dmesg lines on shell I have found this,

 

GENCFG: op for 2 (USP Blob) failed; err 5 (Invalid) minor type: 0x1f. Error originated from pfe type: 10, pfe index: 0, mgmt addr: 0x80000001
pfe_peer_update_mgmt_state: 274: class: 0, type: 10, index: 0, vksid: 0, old state Resync new state Online mastership 1
ge-0/0/0:tag-protocol-id not configurable on this interface
ge-0/0/0 : output-vlan-map is not supported for this interface
if_rtb_default_ifl_bitmap_set() rtb ifl bitmap itable op 1 done. rtb id 0 ifl idx 70 iff 0xfffff800b56984b0.
ge-0/0/1:tag-protocol-id not configurable on this interface
ge-0/0/2:tag-protocol-id not configurable on this interface
if_select_new_rtb_default_ifa() get next ifl idx 70 rtb id 0 iff 0xfffff800b56984b0.

This explains quite well why "tag-protocol-id" and "vlan-maps" do not work at all Smiley Frustrated

↧
↧

Re: SRX 345 QinQ - 802.1ad

October 29, 2019, 10:02 am
$
0
0

Based on the "Configuring Mixed Tagging" section of the following document, it seems that "vlan-tags" option will perform the same funtionality of "vlan-id" in the sense of dictating which logical unti will process the traffic.

 

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-interface-configuring-vlan-tagging.html#id-configuring-vlan-tagging

 

Could it be a MTU problem as stated in that document? Please confirm the MTU on that interface and also gather a "show interfaces extensive ge-0/0/0" to look for any counters increasing that might show any packet drops.


"NOTE: When you configure the physical interface MTU for mixed tagging, you must increase the MTU to 4 bytes more than the MTU value you would configure for a standard VLAN-tagged interface.

 

↧

Re: SRX 345 QinQ - 802.1ad

October 29, 2019, 10:41 am
$
0
0
 wrote:

Based on the "Configuring Mixed Tagging" section of the following document, it seems that "vlan-tags" option will perform the same funtionality of "vlan-id" in the sense of dictating which logical unti will process the traffic.

 

https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-interface-configuring-vlan-tagging.html#id-configuring-vlan-tagging

 

Could it be a MTU problem as stated in that document? Please confirm the MTU on that interface and also gather a "show interfaces extensive ge-0/0/0" to look for any counters increasing that might show any packet drops.


"NOTE: When you configure the physical interface MTU for mixed tagging, you must increase the MTU to 4 bytes more than the MTU value you would configure for a standard VLAN-tagged interface.

 

Hi, Thanks for prompt reply.

 

I doubt that this will be MTU as ARP request is only 50bytes on the wire, that said  I will go ahead and change MTU on the interface and see if that makes any difference.

↧

Re: SRX 345 QinQ - 802.1ad

October 29, 2019, 11:09 am
$
0
0

yap, no difference,

 

Show Interface output below, still no arp on 802.1ad frames

 

root# run show interfaces ge-0/0/0 | match mtu    
  Link-level type: Ethernet, MTU: 1600, LAN-PHY mode, Link-mode: Full-duplex,
    Protocol inet, MTU: 1578

 

↧
Viewing all 17645 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>