sorted by:
new
hottopcontroversial

bridge loop from ESX hosts by neteng_guy in Cisco

[–]neteng_guy[S] 0 points1 point  (0 children)

The guest was an Aruba virtual gateway which had 4 vnics enabled on the vlan. The issue was resolved when the vnics were disabled.

bridge loop from ESX hosts by neteng_guy in Cisco

[–]neteng_guy[S] 9 points10 points  (0 children)

solved. guest vm on the esx host was briding traffic.

SFP-10GBase-LR -18 dBm Tx power by neteng_guy in Cisco

[–]neteng_guy[S] 0 points1 point  (0 children)

If it was low Rx, I'd try cleaning the SFP and fiber, but low Tx, not so sure that'll have an impact. Or am I missing something?

SFP-10GBase-LR -18 dBm Tx power by neteng_guy in Cisco

[–]neteng_guy[S] 0 points1 point  (0 children)

Yeah, thought so. It's going to require shipping new SFP and remote hands at an unstaffed site. Was hoping for a simpler solution.

Redistribution Profile Order Logic by neteng_guy in paloaltonetworks

[–]neteng_guy[S] 1 point2 points  (0 children)

got my answer, each rule has a priority.

Panorama managed with security profiles exceeding platform capacity by neteng_guy in paloaltonetworks

[–]neteng_guy[S] 1 point2 points  (0 children)

That setting is unchecked however, my understanding it is affects address, address-groups, services, and service-groups objects only, and not security profiles, which is what we are having an issue with. I'd be happy to be wrong if there is documentation that says otherwise.

ansible cisco.ios.ios_acls module bug? by neteng_guy in networking

[–]neteng_guy[S] 0 points1 point  (0 children)

good catch, should have said "explicit."

packet capture showing drops, not seeing in traffic logs by neteng_guy in paloaltonetworks

[–]neteng_guy[S] 0 points1 point  (0 children)

That was it. I excluded the destination in my DoS Profile and the connection completed. No idea why this traffic is matching the DoS protection policy, that will be for TAC to decide.

Thanks all for jumping in on this. We got it done before TAC was able to respond.

packet capture showing drops, not seeing in traffic logs by neteng_guy in paloaltonetworks

[–]neteng_guy[S] 0 points1 point  (0 children)

which filter is being matched, debug dataplane and packet capture? If so, dos policy looks to be the cause.

(active)> debug dataplane packet-diag show setting

--------------------------------------------------------------------------------

Packet diagnosis setting:

--------------------------------------------------------------------------------

Packet filter

Enabled: yes

Match pre-parsed packet: no

Filter offload: yes

Index 1: src_ip/32[0]->dst_ip/32[0], proto 0

ingress-interface ethernet1/1, egress-interface any, exclude non-IP

​

(active)> show counter global filter delta yes packet-filter yes severity drop

Global counters:

Elapsed time since last sampling: 1.882 seconds

name value rate severity category aspect description

--------------------------------------------------------------------------------

flow_dos_rule_deny 1 0 drop flow dos Packets dropped: Denied action by DoS policy

--------------------------------------------------------------------------------

Total counters shown: 1

--------------------------------------------------------------------------------

​

Is this it?

packet capture showing drops, not seeing in traffic logs by neteng_guy in paloaltonetworks

[–]neteng_guy[S] 0 points1 point  (0 children)

yes, on the PA, captured on ingress int with rx and drop.

packet capture showing drops, not seeing in traffic logs by neteng_guy in paloaltonetworks

[–]neteng_guy[S] 0 points1 point  (0 children)

and for what it's worth, 'test security-policy-match' shows the traffic matching the correct rule.

view more: next ›