time to live exceeded
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎06-14-2014 11:48 PM
Hi Everyone,
very suddenly our bunch of extreme x670v, x480 become unavailable over management IP address and IP addresses assigned to different vlans.
After an hours of investigation we found that we can access them from the ip addresses of the same subnets assigned over different vlans but all request which are coming from another subnets are dropped.
the problem as we found is in TTL value assigned to the packets which are outcoming from the switch to default gw - it is set to 1. If we do 'ping ttl 10 host' it works fine.
very long time back there was one message in the logs of the 670v: Slot-2: IPv4 multicast entry not added. Hardware L3 Table full. but we don't think that is the case.
we did quite a lot of research overnight in docs and different forums - etc. nothing found.
the configuration is quite simple: we don't use any routing, bgp, ospf, etc.
Please give us clue what can cause that issue and how it can be fixed.
Thanks,
Nikolay
very suddenly our bunch of extreme x670v, x480 become unavailable over management IP address and IP addresses assigned to different vlans.
After an hours of investigation we found that we can access them from the ip addresses of the same subnets assigned over different vlans but all request which are coming from another subnets are dropped.
the problem as we found is in TTL value assigned to the packets which are outcoming from the switch to default gw - it is set to 1. If we do 'ping ttl 10 host' it works fine.
very long time back there was one message in the logs of the 670v: Slot-2: IPv4 multicast entry not added. Hardware L3 Table full. but we don't think that is the case.
we did quite a lot of research overnight in docs and different forums - etc. nothing found.
the configuration is quite simple: we don't use any routing, bgp, ospf, etc.
Please give us clue what can cause that issue and how it can be fixed.
Thanks,
Nikolay
6 REPLIES 6
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎06-15-2014 03:20 AM
Hi Sumit, all done and works now. We are proceeding with the recommendations you've made to prevent this in future. Thanks, Nikolay
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Get Direct Link
- Report Inappropriate Content
‎06-15-2014 02:10 AM
Nikolay,
Use snmp get command to see what is the current TTL value on Extreme device,
a2-emrd-lm-mx.9 # show snmp get 1.3.6.1.2.1.4.2.0
mib_2.4.2.0 = 64
If it's not 64 and showing 1 then use below command on snmp tool to change the ttl value back to 64.
snmpset -r 10 -v 2c -c private 10.67.72.69 .1.3.6.1.2.1.4.2.0 i "64"
I would suggest to check any vulnerable packets are coming from the NMS server which is changing the TTL value.
I would like you to follow below stepsm to avoid this issue in future,
1)Disable the community string which you don't used.
2)Configure the SNMP access profile to allow only certain IP to get the access of switch or you can disable the SNMP access(command: disable snmp access)
Use snmp get command to see what is the current TTL value on Extreme device,
a2-emrd-lm-mx.9 # show snmp get 1.3.6.1.2.1.4.2.0
mib_2.4.2.0 = 64
If it's not 64 and showing 1 then use below command on snmp tool to change the ttl value back to 64.
snmpset -r 10 -v 2c -c private 10.67.72.69 .1.3.6.1.2.1.4.2.0 i "64"
I would suggest to check any vulnerable packets are coming from the NMS server which is changing the TTL value.
I would like you to follow below stepsm to avoid this issue in future,
1)Disable the community string which you don't used.
2)Configure the SNMP access profile to allow only certain IP to get the access of switch or you can disable the SNMP access(command: disable snmp access)
