srx4600 an Cisco Nexus 7000 ping lost [ Edited ]

[#1]

Hello everybody,

I have a problem. The SRX4600 is connected with 10 gigabit to the Nexus 7000. The interface is also up. If I put a ping on the gateway from the firewall now I get massive packet losses. If I try to ping the firewall from the gateway I get no answer

The configuratio:

show configuration interfaces reth2
description xxx;
vlan-tagging;
redundant-ether-options {
redundancy-group 1;
minimum-links 1;
lacp {
passive;
periodic slow;
}
}
unit 427 {
description xxxx;
vlan-id 427;
family inet {
address x.y.x.15/24;
}
}
unit 1503 {
description xxx;
vlan-id 1503;
family inet {
address x.y.x.3/24;
}
}

show configuration interfaces
xe-1/1/0 {
gigether-options {
redundant-parent reth2;
}
}
xe-1/1/1 {
gigether-options {
redundant-parent reth2;
}
}

xe-8/1/0 {
gigether-options {
redundant-parent reth2;
}
}
xe-8/1/1 {
gigether-options {
redundant-parent reth2;

Cisco

interface Ethernet2/31

switchport mode trunk
channel-group 27 mode active

interface Ethernet2/32

switchport mode trunk
channel-group 27 mode active

interface port-channel27

switchport mode trunk

[#2]

regarding heavy ping loss towards NX

REs tend to have implicit ratelimiter for ICMP traffic to prevent overloading

regarding ping to SRX

is the interface bound to a zone and host inbound ping allowed ?

regards

alexander

[#3]

Hi, ANFAFFM

I can see 4 interfaces on the SRX (xe-1/1/0, xe-1/1/1, xe-8/1/0, xe-8/1/1) but only 2 on the Nexus (Ethernet2/31, Ethernet2/32). Can you let us know how are the physical links setup? can you attach the config of the other ports of the Nexus, if they exist?

[#4]

From the configs posted it looks like you have the Cisco setup as a LAG and the SRX is using redundant ethernet.

Redundant ethernet is an active passive switchover of the dual ports while LAG has both active.  You need to change the cisco to be simple access or trunk ports for the RETH pairs on the SRX.  The SRX will only send traffic out the active port and will garp when a switchover occurs.

[#5]

Hello,

This is correct, instead of using port channel mode active you need to use mode "on" which does not run LACP. I understand from the Cisco documentation that the default mode is on.

Regards,

Vikas

[#6]

The other two interfaces hang on the other nexus and are connected to the secondary node of the SRX. The config is the same. Currently the interface is at the secondary for the test down.

[#7]

When I'm on mode, I'm not driving LACP on the Nexus anymore. I want to do LACP.
I use the same configuration synonymous with a SRX3600 here everything runs without a problem.
the SRX4600 should replace the SRX3600 in the future and got the same configuration.
The interface is bound to a zone and it allows traffic inbound.

show configuration security zones security-zone xy

host-inbound-traffic {
system-services {
ssh;
ping;
https;
snmp;
snmp-trap;
traceroute;
}
}
interfaces {
reth2.1503;
}

[#8]

It sounds like two problems:

1. Port-channels are not configured properly

2. You have not allowed inbound traffic to the SRX reth logical interface.

Regarding 1)

You can still use LACP on your links with SRX chassis clusters. You just need a port-channel towards each node in the cluster.

Figure 1 on the following page gives a good overview on how it should be implemented.

https://www.juniper.net/documentation/en_US/junos/topics/example/interface-security-aggregated-ether....

Regarding 2)

Please let us know which vlan you are testing with (reth2.427 or reth2.1503) and provide configuration for the security-zone where interface is attached ('show configuration security zones security-zone XXX').

Also share output from the SRX cluster on the following :

'show chassis cluster status'

'show chassis cluster interfaces'

'show lacp interfaces'

Please also provide status on the interfaces on the Nexus switches including lacp and active member interfaces on the port-channel.

[#9]

show chassis cluster status
Monitor Failure codes:
CS Cold Sync monitoring FL Fabric Connection monitoring
GR GRES monitoring HW Hardware monitoring
IF Interface monitoring IP IP monitoring
LB Loopback monitoring MB Mbuf monitoring
NH Nexthop monitoring NP NPC monitoring
SP SPU monitoring SM Schedule monitoring
CF Config Sync monitoring

Cluster ID: 1
Node Priority Status Preempt Manual Monitor-failures

Redundancy group: 0 , Failover count: 3
node0 1 primary no no None
node1 1 secondary no no None

Redundancy group: 1 , Failover count: 5
node0 0 primary no no IF
node1 0 secondary no no IF

Redundancy group: 2 , Failover count: 1
node0 0 primary no no IF
node1 0 secondary no no IF

show chassis cluster interfaces
Control link status: Up

Control interfaces:
Index Interface Monitored-Status Internal-SA Security
0 em0 Up Disabled Disabled
1 em1 Up Disabled Disabled

Fabric link status: Up

Fabric interfaces:
Name Child-interface Status Security
(Physical/Monitored)
fab0 xe-0/0/2 Up / Up Disabled
fab0 xe-0/0/3 Up / Up Disabled
fab1 xe-7/0/2 Up / Up Disabled
fab1 xe-7/0/3 Up / Up Disabled

Redundant-ethernet Information:
Name Status Redundancy-group
reth0 Down 2
reth1 Down 1
reth2 Up 1

Redundant-pseudo-interface Information:
Name Status Redundancy-group
lo0 Up 0

Interface Monitoring:
Interface Weight Status Redundancy-group
xe-8/1/3 128 Down 1
xe-8/1/1 128 Down 1
xe-8/1/0 128 Down 1
xe-1/1/4 128 Down 1
xe-1/1/3 128 Down 1
xe-1/1/1 128 Up 1
xe-1/1/0 128 Up 1
xe-8/1/2 255 Down 2
xe-1/1/2 255 Down 2

show lacp interfaces reth2
Aggregated interface: reth2
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
xe-1/1/0 Actor No No Yes Yes Yes Yes Slow Passive
xe-1/1/0 Partner No No Yes Yes Yes Yes Slow Active
xe-1/1/1 Actor No No Yes Yes Yes Yes Slow Passive
xe-1/1/1 Partner No No Yes Yes Yes Yes Slow Active
xe-8/1/0 Actor No Yes No No No Yes Slow Passive
xe-8/1/0 Partner No Yes No No No Yes Fast Passive
xe-8/1/1 Actor No Yes No No No Yes Slow Passive
xe-8/1/1 Partner No Yes No No No Yes Fast Passive
LACP protocol: Receive State Transmit State Mux State
xe-1/1/0 Current Slow periodic Collecting distributing
xe-1/1/1 Current Slow periodic Collecting distributing
xe-8/1/0 Port disabled No periodic Detached
xe-8/1/1 Port disabled No periodic Detached

I have already done it as described on the page. Here is the only difference that LACP is active. But this brought no difference

Test runs with reth2.1503

Configuration of the zone see post before!

Nexus status of the port-chnnel:

sh port-channel summary

Flags: D - Down P - Up in port-channel (members)
I - Individual H - Hot-standby (LACP only)
s - Suspended r - Module-removed
S - Switched R - Routed
U - Up (port-channel)
M - Not in use. Min-links not met

27 Po27(SU)   Eth LACP    Eth2/31(P)     Eth2/32(P)

[#10]

Hi,

> LACP looks fine, it would be worthwhile shutting one interfact at a time to see if the issue disappears? 

> Do you see the LACP to be stable - collecting distributing state at all times?

> While you are pining the IP on the firewall, you could ping with a specific packet count and do a "monitor traffic interface reth2.1503" to understand if we received and responded to all the requests.

Regards,

Vikas

[#11]

LACP looks fine, it would be worthwhile shutting one interfact at a time to see if the issue disappears?,

--> Already had only one interface in the channel in it the Eergbnis is the same.

How exactly can I build a Moonitor?

[#12]

Hello,

Sorry, to persist on this. Did you try removing the interfaces from the reth one at the time? It could potentially lead us to one of the interface causing the issue. I meant case1: xe-1/1/0 part of reth2 and case 2: xe-1/1/1 part of reth2.

Running monitor on the RE is an operational level command. Below is an example:

> root@srx> monitor traffic interface reth2.1503 no-resolve

In addition please collect the following command outputs before and after the ping failures:

> show interfaces extensive | no-more

> request pfe execute target node0.fpc0 command "show usp flow counters all" | no-more

Regards,

Vikas

[#13]

I once cut at the destination.
There I can see the packages on the interface and the answer packages go out.

For example, I have seen 8 packets but the SRX has only received 3

[#14]

Sorry, to persist on this. Did you try removing the interfaces from the reth one at the time? It could potentially lead us to one of the interface causing the issue. I meant case1: xe-1/1/0 part of reth2 and case 2: xe-1/1/1 part of reth2.

--> Do you think I should put the ip and the vlan on an interface directly and not on a reth interface?

[#15]

The configuration on the Cisco needs to change and REMOVE the LAG/Port channel.

You cannot connect RETH to a LAG/Port channel.

Instead, you configure the two Cisco interfaces as one of two ways:

1-access untagged port if you have only one VLAN on this RETH

or

2-trunk port with all the VLAN tags that are configured on the RETH port

RETH is Redundant ethernet standard NOT a LAG.

[#16]

Hello,

Since you are seeing only 3 of the 8 packets sent could be a port channel issue. You can try putting the IP on the interface.

Best Regards,

Vikas

[#17]

Hello Steve,

LACP is configured on the reth2 as well and is in a healthy state.

Best Regards,

Vikas

[#18]

I promise the configuration I suggest will work as I have used it on many setups including with Cisco switches.

And I have seen the symptoms described here when attempting to connect LAG to RETH ports as the standards for redundant ethernet and aggregated ethernet are slightly different.

[#19]

434/5000

I looked at this morning again.
In the same network is currently still the SRX3600 this has the same configuration as the new SRX except the IP address. The SRX 3600 has the x.y.x.1 and the new SRX has the x.y.x.2.
Now I noticed that the interface reth2 on both firewalls have the same MAC address.
SRX3600 00: 10: db: ff: 10: 02
SRX4600 00: 10: db: ff: 10: 02

Is there a way to change it?

[#20]

reth interface's mac address is derived from cluster id and interface id. So if you change cluster id or reth interface number (reth0 to reth1, reth1 to reth2 etc) of one cluster, the mac address will be different. Please follow this KB for more details: https://kb.juniper.net/InfoCenter/index?page=content&id=KB13689&actp=METADATA&act=login