<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Using the S/N/K-Series Router Debug Packet Filter to resolve Ping Issue in FAQs</title>
    <link>https://community.extremenetworks.com/t5/faqs/using-the-s-n-k-series-router-debug-packet-filter-to-resolve/m-p/42850#M136</link>
    <description>Article ID: 14495 &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Products&lt;/B&gt;&lt;BR /&gt;
S-Series, all firmware&lt;BR /&gt;
Matrix N-Series DFE, firmware 6.01.01.0020 and higher&lt;BR /&gt;
K-Series, all firmware &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Discussion&lt;/B&gt;&lt;BR /&gt;
This is an additional use of the router "Debug IP/Packet" feature, furthering what is explained in &lt;A href="http://bit.ly/1hcCASC" target="_blank" rel="nofollow noreferrer noopener"&gt;14661&lt;/A&gt;. &lt;BR /&gt;
&lt;BR /&gt;
In the case of a user not being able to ping a (S/N/K-Series) switch yet being able to ping through it to end stations on the other side, the debug packet filter command may be used to determine where and why the pings are dropped by the local switch-host. &lt;BR /&gt;
&lt;BR /&gt;
Given that the non-replying switch-host's IP address is 192.168.3.2, create an access-list that which is then used to apply a filter to the debug ip packet process to look for this specific address only.S3(su)-&amp;gt;router&lt;BR /&gt;
S3(su-router)-&amp;gt;configure&lt;BR /&gt;
S3(su-router-config)-&amp;gt;ip access-list extended vlan1326&lt;BR /&gt;
S3(su-router-cfg-ext-acl-vlan1326)-&amp;gt;permit icmp any host 192.168.3.2&lt;BR /&gt;
S3(su-router-cfg-ext-acl-vlan1326)-&amp;gt;permit icmp host 192.168.3.2 any&lt;BR /&gt;
S3(su-router-cfg-ext-acl-vlan1326)-&amp;gt;exit&lt;BR /&gt;
 &lt;BR /&gt;
S3(su-router-config)-&amp;gt;debug packet control limit 30&lt;BR /&gt;
S3(su-router-config)-&amp;gt;set logging here enable&lt;BR /&gt;
S3(su-router-config)-&amp;gt;debug packet filter access-list vlan1326&lt;BR /&gt;
 &lt;BR /&gt;
S3(su-router-config)-&amp;gt;&amp;lt;165&amp;gt;Feb 25 19:52:06 10.0.30.4 DbgIpPkt[1][1]&lt;BR /&gt;
[send] Rule hit[2: permit icmp host 192.168.3.2 any] out intf 2090, PKT:&lt;BR /&gt;
InPort(ge.1.7) LEN(78) DA(00:1F:45:A1:3D:CB) SA(00:11:88:E5:F1:E0)&lt;BR /&gt;
TAG(8100:452E) ETYPE(0800) SIP(192.168.3.2) DIP(10.0.0.9) VER(4) HLEN(5)&lt;BR /&gt;
TOTALLEN(56) PROTO(1) TOS(192) TTL(30) ICMP(3:1) , *** FATE: Forwarding,&lt;BR /&gt;
192.168.90.1, out port ge.1.47, flow allowed&lt;BR /&gt;
&amp;lt;165&amp;gt;Feb 25 19:53:17 10.0.30.4 HostDoS[1] Attack ( icmpFlood ) detected&lt;BR /&gt;
on vlan.0.1326 [ InPort(ge.1.7) LEN(106) DA(00:1F:45:A1:3D:CB)&lt;BR /&gt;
SA(00:11:88:E5:F1:E0) TAG(8100:452E) ETYPE(0800) SIP(10.3.0.2)&lt;BR /&gt;
DIP(192.168.3.1) VER(4) HLEN(5) TOTALLEN(84) PROTO(1) TOS(0) TTL(63)&lt;BR /&gt;
ICMP(8:0) ]In this case we can see that the HostDos icmpFlood mechanism is what dropped the packet.&lt;BR /&gt;
Therefore, disabling HostDoS icmpFlood (or setting its rate to some non-zero value) will resolve the issue.&lt;BR /&gt;
(Note that with firmware 7.91.01.xxxx and higher, the default hostDoS rate settings for icmpFlood and synFlood are 4294967294 rather than zero.) &lt;BR /&gt;
&lt;BR /&gt;
After reaching a conclusion, the test configuration may be removed.debug packet stop&lt;BR /&gt;
S3(su-router-config)-&amp;gt;set logging here disable&lt;BR /&gt;
S3(su-router-config)-&amp;gt;no ip access-list extended vlan1326&lt;BR /&gt;
S3(su-router-config)-&amp;gt;exit&lt;BR /&gt;
S3(su-router)-&amp;gt;exit&lt;BR /&gt;
S3(su)-&amp;gt;Also see this &lt;A href="https://www.youtube.com/watch?v=y6fQbRaJ14k&amp;amp;#38;list=PLvQMiI4QwvHTFYkDRLl_8NUE8Ijp5Zm8n&amp;amp;#38;index=53" target="_blank" rel="nofollow noreferrer noopener"&gt;HowTo Video&lt;/A&gt; which demonstrates use of the "Debug IP/Packet" feature.&lt;BR /&gt;</description>
    <pubDate>Tue, 31 Dec 2013 23:47:00 GMT</pubDate>
    <dc:creator>FAQ_User</dc:creator>
    <dc:date>2013-12-31T23:47:00Z</dc:date>
    <item>
      <title>Using the S/N/K-Series Router Debug Packet Filter to resolve Ping Issue</title>
      <link>https://community.extremenetworks.com/t5/faqs/using-the-s-n-k-series-router-debug-packet-filter-to-resolve/m-p/42850#M136</link>
      <description>Article ID: 14495 &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Products&lt;/B&gt;&lt;BR /&gt;
S-Series, all firmware&lt;BR /&gt;
Matrix N-Series DFE, firmware 6.01.01.0020 and higher&lt;BR /&gt;
K-Series, all firmware &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Discussion&lt;/B&gt;&lt;BR /&gt;
This is an additional use of the router "Debug IP/Packet" feature, furthering what is explained in &lt;A href="http://bit.ly/1hcCASC" target="_blank" rel="nofollow noreferrer noopener"&gt;14661&lt;/A&gt;. &lt;BR /&gt;
&lt;BR /&gt;
In the case of a user not being able to ping a (S/N/K-Series) switch yet being able to ping through it to end stations on the other side, the debug packet filter command may be used to determine where and why the pings are dropped by the local switch-host. &lt;BR /&gt;
&lt;BR /&gt;
Given that the non-replying switch-host's IP address is 192.168.3.2, create an access-list that which is then used to apply a filter to the debug ip packet process to look for this specific address only.S3(su)-&amp;gt;router&lt;BR /&gt;
S3(su-router)-&amp;gt;configure&lt;BR /&gt;
S3(su-router-config)-&amp;gt;ip access-list extended vlan1326&lt;BR /&gt;
S3(su-router-cfg-ext-acl-vlan1326)-&amp;gt;permit icmp any host 192.168.3.2&lt;BR /&gt;
S3(su-router-cfg-ext-acl-vlan1326)-&amp;gt;permit icmp host 192.168.3.2 any&lt;BR /&gt;
S3(su-router-cfg-ext-acl-vlan1326)-&amp;gt;exit&lt;BR /&gt;
 &lt;BR /&gt;
S3(su-router-config)-&amp;gt;debug packet control limit 30&lt;BR /&gt;
S3(su-router-config)-&amp;gt;set logging here enable&lt;BR /&gt;
S3(su-router-config)-&amp;gt;debug packet filter access-list vlan1326&lt;BR /&gt;
 &lt;BR /&gt;
S3(su-router-config)-&amp;gt;&amp;lt;165&amp;gt;Feb 25 19:52:06 10.0.30.4 DbgIpPkt[1][1]&lt;BR /&gt;
[send] Rule hit[2: permit icmp host 192.168.3.2 any] out intf 2090, PKT:&lt;BR /&gt;
InPort(ge.1.7) LEN(78) DA(00:1F:45:A1:3D:CB) SA(00:11:88:E5:F1:E0)&lt;BR /&gt;
TAG(8100:452E) ETYPE(0800) SIP(192.168.3.2) DIP(10.0.0.9) VER(4) HLEN(5)&lt;BR /&gt;
TOTALLEN(56) PROTO(1) TOS(192) TTL(30) ICMP(3:1) , *** FATE: Forwarding,&lt;BR /&gt;
192.168.90.1, out port ge.1.47, flow allowed&lt;BR /&gt;
&amp;lt;165&amp;gt;Feb 25 19:53:17 10.0.30.4 HostDoS[1] Attack ( icmpFlood ) detected&lt;BR /&gt;
on vlan.0.1326 [ InPort(ge.1.7) LEN(106) DA(00:1F:45:A1:3D:CB)&lt;BR /&gt;
SA(00:11:88:E5:F1:E0) TAG(8100:452E) ETYPE(0800) SIP(10.3.0.2)&lt;BR /&gt;
DIP(192.168.3.1) VER(4) HLEN(5) TOTALLEN(84) PROTO(1) TOS(0) TTL(63)&lt;BR /&gt;
ICMP(8:0) ]In this case we can see that the HostDos icmpFlood mechanism is what dropped the packet.&lt;BR /&gt;
Therefore, disabling HostDoS icmpFlood (or setting its rate to some non-zero value) will resolve the issue.&lt;BR /&gt;
(Note that with firmware 7.91.01.xxxx and higher, the default hostDoS rate settings for icmpFlood and synFlood are 4294967294 rather than zero.) &lt;BR /&gt;
&lt;BR /&gt;
After reaching a conclusion, the test configuration may be removed.debug packet stop&lt;BR /&gt;
S3(su-router-config)-&amp;gt;set logging here disable&lt;BR /&gt;
S3(su-router-config)-&amp;gt;no ip access-list extended vlan1326&lt;BR /&gt;
S3(su-router-config)-&amp;gt;exit&lt;BR /&gt;
S3(su-router)-&amp;gt;exit&lt;BR /&gt;
S3(su)-&amp;gt;Also see this &lt;A href="https://www.youtube.com/watch?v=y6fQbRaJ14k&amp;amp;#38;list=PLvQMiI4QwvHTFYkDRLl_8NUE8Ijp5Zm8n&amp;amp;#38;index=53" target="_blank" rel="nofollow noreferrer noopener"&gt;HowTo Video&lt;/A&gt; which demonstrates use of the "Debug IP/Packet" feature.&lt;BR /&gt;</description>
      <pubDate>Tue, 31 Dec 2013 23:47:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/faqs/using-the-s-n-k-series-router-debug-packet-filter-to-resolve/m-p/42850#M136</guid>
      <dc:creator>FAQ_User</dc:creator>
      <dc:date>2013-12-31T23:47:00Z</dc:date>
    </item>
  </channel>
</rss>

