Красивый способ отправки писем из консоли. Позволяет работать через бесплатные сервера и в частности google.
Офф сайт - http://caspian.dotconf.net/menu/Software/SendEmail/
Спасибо xloroff
пятница, 29 октября 2010 г.
среда, 27 октября 2010 г.
Freenet6 работает! Работает из под nat! Пока правда в тепличных условиях виртуальных машин, но довольно стабильно. Пинг около 700мс. С одним аккаунтом на разным машинам выдаются разные адреса, после нескольких переподключений адреса не менялись.
Существует небольшой баг с Debian системах. Клиент freenet6 (a.k.a. gw6c, gogoc) при запуске sudo /etc/init.d/gw6c выдает ошибку - что-то про отсутствие ключа для сервера. Решается запуском sudo gw6c. В этом случае программа спросит, желаете ли импортировать ключ.
При первоначальной настройке в /etc/gw6c/gw6c.conf кроме пользователя, пароля и сервера неплохо сразу настроить лог.
ssh ipv6 to ipv6 работает на ура, ipv4 to ipv6 (по доменному имени) пытается подключиться к серверу freenet6.
Было бы отлично, если бы один из шлюзов ipv4toipv6 стоял на MSK-IX, а еще лучше на SPB-IX...
Существует небольшой баг с Debian системах. Клиент freenet6 (a.k.a. gw6c, gogoc) при запуске sudo /etc/init.d/gw6c выдает ошибку - что-то про отсутствие ключа для сервера. Решается запуском sudo gw6c. В этом случае программа спросит, желаете ли импортировать ключ.
При первоначальной настройке в /etc/gw6c/gw6c.conf кроме пользователя, пароля и сервера неплохо сразу настроить лог.
ssh ipv6 to ipv6 работает на ура, ipv4 to ipv6 (по доменному имени) пытается подключиться к серверу freenet6.
Было бы отлично, если бы один из шлюзов ipv4toipv6 стоял на MSK-IX, а еще лучше на SPB-IX...
понедельник, 25 октября 2010 г.
Продвигаем IPv6!
freenet6
Довольно интересное и простое решение для связи с pc за nat.
В ближайшее время попробую поставить на сервер за nat и получить для него IPv6.
Спасибо http://welinux.ru/post/264/
Довольно интересное и простое решение для связи с pc за nat.
В ближайшее время попробую поставить на сервер за nat и получить для него IPv6.
Спасибо http://welinux.ru/post/264/
четверг, 21 октября 2010 г.
Gmail на своём домене.
Gmail на своём домене. Весьма интересный сервис от Google, о котором я не знал до недавнего времени.
Возможности:
Возможности:
- ящик вида name@domain.ru
- возможность предоставлять ящики на домене другим людям
- поддержка POP, SMTP, IMAP
- около 7 ГГБ под почтовый ящик
- ваша почта будет независима от хостинга, даже если у вас не будет хостинга
- надежность, удобство почты Google
Спасибо http://www.odmin4eg.ru
вторник, 19 октября 2010 г.
Инфа по стандартам IEEE 802.3
Инфа по стандартам IEEE 802.3, в одном месте и на русском.
http://wiki.oszone.net/index.php/IEEE_802.3
http://wiki.oszone.net/index.php/IEEE_802.3
понедельник, 18 октября 2010 г.
Extreme Networks blog on techopsguys
Extreme Networks tech blog on techopsguys.
http://www.techopsguys.com/tag/extremenetworks/
http://www.techopsguys.com/tag/extremenetworks/
пятница, 15 октября 2010 г.
четверг, 14 октября 2010 г.
ELRP, UPM и лицензии...
Добавили в скрипты автоматическое включение порта после disable по петле.
В UPM профиль выключения порта добавили:
set var Loop_Port $EVENT.LOG_PARAM_7
save var key 1 Loop_Port
configure upm timer "Enable_Looped_Port" after 60
Создали UPM профиль включения порта:
load var key 1 Loop_Port
enable port $Loop_Port
create log entry "Port $Loop_Port has been enabled"
delete var key 1
В UPM профиль выключения порта добавили:
set var Loop_Port $EVENT.LOG_PARAM_7
save var key 1 Loop_Port
configure upm timer "Enable_Looped_Port" after 60
Создали UPM профиль включения порта:
load var key 1 Loop_Port
enable port $Loop_Port
create log entry "Port $Loop_Port has been enabled"
delete var key 1
Создали таймер на 60 секунд, который вызывает скрипт Enable_Looped_Port:
cre upm timer Enable_Looped_Port
conf upm timer "Enable_Looped_Port" profile "Enable_Looped_Port"
З.Ы. UPM не поддерживается на x150 и x350 моделях. На них лицензия L2 Edge, а нужна Edge License. Видимо поэтому фичу выключения порта по ELRP встроили в XOS, что бы пользователи имели возможность гасить порты на коммутаторах нижнего ценового диапазона.
cre upm timer Enable_Looped_Port
conf upm timer "Enable_Looped_Port" profile "Enable_Looped_Port"
З.Ы. UPM не поддерживается на x150 и x350 моделях. На них лицензия L2 Edge, а нужна Edge License. Видимо поэтому фичу выключения порта по ELRP встроили в XOS, что бы пользователи имели возможность гасить порты на коммутаторах нижнего ценового диапазона.
вторник, 12 октября 2010 г.
Забираем конфиг со свитча
Чтобы слить со свитча конфиг
в ascii - upload configuration
в xml - tftp put
Аларм Device Reboot
Обнаружился очередной прикол. Если на свитче с XOS 12.4.x неправильно настроено системное время, то EPICenter каждые пять минут присылает аларм Device Reboot. Лечится настройкой времени.
пятница, 8 октября 2010 г.
Конспект по типам ACL от Cisco
ACL types described here:
Standard ACLs
Standard ACLs control traffic by the comparison of the source address of the IP packets to the addresses configured in the ACL.
The access-list-number can be anything from 1 to 99 and 1300 to 1999.
This is the command syntax format of a standard ACL.
access-list access-list-number {permit|deny}
{host|source source-wildcard|any}
A source/source-wildcard setting of 0.0.0.0/255.255.255.255 can be specified as any. The wildcard can be omitted if it is all zeros. Therefore, host 10.1.1.2 0.0.0.0 is the same as host 10.1.1.2.
After the ACL is defined, it must be applied to the interface (inbound or outbound).
interface <interface>
ip access-group number {in|out}
This is an example of the use of a standard ACL in order to block all traffic except that from source 10.1.1.x.
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip access-group 1 in
access-list 1 permit 10.1.1.0 0.0.0.255
Extended ACLs
Extended ACLs control traffic by the comparison of the source and destination addresses of the IP packets to the addresses configured in the ACL.
The access-list-number can be 101 to 199 and 2000 to 2699.
access-list access-list-number [dynamic dynamic-name [timeout minutes]]
{deny | permit} {ip | icmp | tcp | udp} source source-wildcard [port (if not ip)]
destination destination-wildcard ... lot of stuff
interface <interface>
ip access-group {number|name} {in|out}
This extended ACL is used to permit traffic on the 10.1.1.x network (inside) and to receive ping responses from the outside while it prevents unsolicited pings from people outside, permitting all other traffic.
interface Ethernet0/1
ip address 172.16.1.2 255.255.255.0
ip access-group 101 in
access-list 101 deny icmp any 10.1.1.0 0.0.0.255 echo
access-list 101 permit ip any 10.1.1.0 0.0.0.255
Lock and Key (Dynamic ACLs)
Lock and key configuration starts with the application of an extended ACL to block traffic through the router. Users that want to traverse the router are blocked by the extended ACL until they Telnet to the router and are authenticated. The Telnet connection then drops and a single-entry dynamic ACL is added to the extended ACL that exists. This permits traffic for a particular time period; idle and absolute timeouts are possible.
IP Named ACLs
This allows standard and extended ACLs to be given names instead of numbers.
This is the command syntax format for IP named ACLs.
ip access-list {extended|standard} name
This is an example of the use of a named ACL in order to block all traffic except the Telnet connection from host 10.1.1.2 to host 172.16.1.1.
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip access-group in_to_out in
ip access-list extended in_to_out
permit tcp host 10.1.1.2 host 172.16.1.1 eq telnet
Reflexive ACLs
Reflexive ACLs were introduced in Cisco IOS Software Release 11.3. Reflexive ACLs allow IP packets to be filtered based on upper-layer session information. They are generally used to allow outbound traffic and to limit inbound traffic in response to sessions that originate inside the router.
Reflexive ACLs can be defined only with extended named IP ACLs. They cannot be defined with numbered or standard named IP ACLs, or with other protocol ACLs. Reflexive ACLs can be used in conjunction with other standard and static extended ACLs.
This is the syntax for various reflexive ACL commands.
interface
ip access-group {number|name} {in|out}
ip access-list extended name
permit protocol any any reflect name [timeoutseconds]
ip access-list extended name
evaluate name
This is an example of the permit of ICMP outbound and inbound traffic, while only permitting TCP traffic that has initiated from inside, other traffic is denied.
ip reflexive-list timeout 120
interface Ethernet0/1
ip address 172.16.1.2 255.255.255.0
ip access-group inboundfilters in
ip access-group outboundfilters out
ip access-list extended inboundfilters
permit icmp 172.16.1.0 0.0.0.255 10.1.1.0 0.0.0.255
evaluate tcptraffic
!--- This ties the reflexive ACL part of the outboundfilters ACL,
!--- called tcptraffic, to the inboundfilters ACL.
ip access-list extended outboundfilters
permit icmp 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255
permit tcp 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255 reflect tcptraffic
Time-Based ACLs Using Time Ranges
While similar to extended ACLs in function, they allow for access control based on time. A time range is created that defines specific times of the day and week in order to implement time-based ACLs. The time range is identified by a name and then referenced by a function. Therefore, the time restrictions are imposed on the function itself. The time range relies on the router system clock.
These are time-based ACL commands.
!--- Defines a named time range.
time-range time-range-name
!--- Defines the periodic times.
periodic days-of-the-week hh:mm to [days-of-the-week] hh:mm
!--- Or, defines the absolute times.
absolute [start time date] [end time date]
!--- The time range used in the actual ACL.
ip access-list name|number <extended_definition>time-rangename_of_time-range
In this example, a Telnet connection is permitted from the inside to outside network on Monday, Wednesday, and Friday during business hours:
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip access-group 101 in
access-list 101 permit tcp 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255
eq telnet time-range EVERYOTHERDAY
time-range EVERYOTHERDAY
periodic Monday Wednesday Friday 8:00 to 17:00
Commented IP ACL Entries
Comments make ACLs easier to understand and can be used for standard or extended IP ACLs.
This is the commented name IP ACL command syntax.
ip access-list {standard|extended} name
remark remark
This is the commented numbered IP ACL command syntax.
access-list access-list-number remark remark
Context-Based Access Control
CBAC inspects traffic that travels through the firewall in order to discover and manage state information for TCP and UDP sessions. This state information is used in order to create temporary openings in the access lists of the firewall. Configure ip inspect lists in the direction of the flow of traffic initiation in order to allow return traffic and additional data connections for permissible session, sessions that originated from within the protected internal network, in order to do this.
Authentication Proxy
Authentication proxy is used to authenticate inbound or outbound users, or both. Users who are normally blocked by an ACL can bring up a browser to go through the firewall and authenticate on a TACACS+ or RADIUS server. The server passes additional ACL entries down to the router in order to allow the users through after authentication.
Turbo ACLs
Turbo ACLs are found only on the 7200, 7500, and other high-end platforms. The turbo ACL feature is designed in order to process ACLs more efficiently in order to improve router performance.
Use the access-list compiled command for turbo ACLs. This is an example of a compiled ACL.
access-list 101 permit tcp host 10.1.1.2 host 172.16.1.1 eq telnet
access-list 101 permit tcp host 10.1.1.2 host 172.16.1.1 eq ftp
access-list 101 permit udp host 10.1.1.2 host 172.16.1.1 eq syslog
access-list 101 permit udp host 10.1.1.2 host 172.16.1.1 eq tftp
access-list 101 permit udp host 10.1.1.2 host 172.16.1.1 eq ntp
After the standard or extended ACL is defined, use the global configuration command in order to compile.
!--- Tells the router to compile
access-list compiled
Interface Ethernet0/1
ip address 172.16.1.2 255.255.255.0
!--- Applies to the interface
ip access-group 101 in
The show access-list compiled command shows statistics about the ACL.
Distributed Time-Based ACLs
Distributed time-based ACLs were introduced order to implement time-based ACLs on VPN-enabled 7500 series routers.
Receive ACLs
Receive ACLs are used in order to increase security on Cisco 12000 routers by the protection of the gigabit route processor (GRP) of the router from unnecessary and potentially nefarious traffic.
Infrastructure Protection ACLs
Infrastructure ACLs are used in order to minimize the risk and effectiveness of direct infrastructure attack by the explicit permission of only authorized traffic to the infrastructure equipment while permitting all other transit traffic.
Transit ACLs
Transit ACLs are used in order to increase network security since they explicitly permit only required traffic into your network or networks.
Protocols with Access Lists Specified by Numbers
Protocol Range
Текст взят с сайта cisco.com
- Standard ACLs
- Extended ACLs
- Lock and Key (Dynamic ACLs)
- IP Named ACLs
- Reflexive ACLs
- Time-Based ACLs Using Time Ranges
- Commented IP ACL Entries
- Context-Based Access Control
- Authentication Proxy
- Turbo ACLs
- Distributed Time-Based ACLs
- Receive ACLs
- Infrastructure Protection ACLs
- Transit ACLs
Standard ACLs
Standard ACLs control traffic by the comparison of the source address of the IP packets to the addresses configured in the ACL.
The access-list-number can be anything from 1 to 99 and 1300 to 1999.
This is the command syntax format of a standard ACL.
access-list access-list-number {permit|deny}
{host|source source-wildcard|any}
A source/source-wildcard setting of 0.0.0.0/255.255.255.255 can be specified as any. The wildcard can be omitted if it is all zeros. Therefore, host 10.1.1.2 0.0.0.0 is the same as host 10.1.1.2.
After the ACL is defined, it must be applied to the interface (inbound or outbound).
interface <interface>
ip access-group number {in|out}
This is an example of the use of a standard ACL in order to block all traffic except that from source 10.1.1.x.
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip access-group 1 in
access-list 1 permit 10.1.1.0 0.0.0.255
Extended ACLs
Extended ACLs control traffic by the comparison of the source and destination addresses of the IP packets to the addresses configured in the ACL.
The access-list-number can be 101 to 199 and 2000 to 2699.
access-list access-list-number [dynamic dynamic-name [timeout minutes]]
{deny | permit} {ip | icmp | tcp | udp} source source-wildcard [port (if not ip)]
destination destination-wildcard ... lot of stuff
interface <interface>
ip access-group {number|name} {in|out}
This extended ACL is used to permit traffic on the 10.1.1.x network (inside) and to receive ping responses from the outside while it prevents unsolicited pings from people outside, permitting all other traffic.
interface Ethernet0/1
ip address 172.16.1.2 255.255.255.0
ip access-group 101 in
access-list 101 deny icmp any 10.1.1.0 0.0.0.255 echo
access-list 101 permit ip any 10.1.1.0 0.0.0.255
Lock and Key (Dynamic ACLs)
Lock and key configuration starts with the application of an extended ACL to block traffic through the router. Users that want to traverse the router are blocked by the extended ACL until they Telnet to the router and are authenticated. The Telnet connection then drops and a single-entry dynamic ACL is added to the extended ACL that exists. This permits traffic for a particular time period; idle and absolute timeouts are possible.
IP Named ACLs
This allows standard and extended ACLs to be given names instead of numbers.
This is the command syntax format for IP named ACLs.
ip access-list {extended|standard} name
This is an example of the use of a named ACL in order to block all traffic except the Telnet connection from host 10.1.1.2 to host 172.16.1.1.
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip access-group in_to_out in
ip access-list extended in_to_out
permit tcp host 10.1.1.2 host 172.16.1.1 eq telnet
Reflexive ACLs
Reflexive ACLs were introduced in Cisco IOS Software Release 11.3. Reflexive ACLs allow IP packets to be filtered based on upper-layer session information. They are generally used to allow outbound traffic and to limit inbound traffic in response to sessions that originate inside the router.
Reflexive ACLs can be defined only with extended named IP ACLs. They cannot be defined with numbered or standard named IP ACLs, or with other protocol ACLs. Reflexive ACLs can be used in conjunction with other standard and static extended ACLs.
This is the syntax for various reflexive ACL commands.
interface
ip access-group {number|name} {in|out}
ip access-list extended name
permit protocol any any reflect name [timeoutseconds]
ip access-list extended name
evaluate name
This is an example of the permit of ICMP outbound and inbound traffic, while only permitting TCP traffic that has initiated from inside, other traffic is denied.
ip reflexive-list timeout 120
interface Ethernet0/1
ip address 172.16.1.2 255.255.255.0
ip access-group inboundfilters in
ip access-group outboundfilters out
ip access-list extended inboundfilters
permit icmp 172.16.1.0 0.0.0.255 10.1.1.0 0.0.0.255
evaluate tcptraffic
!--- This ties the reflexive ACL part of the outboundfilters ACL,
!--- called tcptraffic, to the inboundfilters ACL.
ip access-list extended outboundfilters
permit icmp 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255
permit tcp 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255 reflect tcptraffic
Time-Based ACLs Using Time Ranges
While similar to extended ACLs in function, they allow for access control based on time. A time range is created that defines specific times of the day and week in order to implement time-based ACLs. The time range is identified by a name and then referenced by a function. Therefore, the time restrictions are imposed on the function itself. The time range relies on the router system clock.
These are time-based ACL commands.
!--- Defines a named time range.
time-range time-range-name
!--- Defines the periodic times.
periodic days-of-the-week hh:mm to [days-of-the-week] hh:mm
!--- Or, defines the absolute times.
absolute [start time date] [end time date]
!--- The time range used in the actual ACL.
ip access-list name|number <extended_definition>time-rangename_of_time-range
In this example, a Telnet connection is permitted from the inside to outside network on Monday, Wednesday, and Friday during business hours:
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
ip access-group 101 in
access-list 101 permit tcp 10.1.1.0 0.0.0.255 172.16.1.0 0.0.0.255
eq telnet time-range EVERYOTHERDAY
time-range EVERYOTHERDAY
periodic Monday Wednesday Friday 8:00 to 17:00
Commented IP ACL Entries
Comments make ACLs easier to understand and can be used for standard or extended IP ACLs.
This is the commented name IP ACL command syntax.
ip access-list {standard|extended} name
remark remark
This is the commented numbered IP ACL command syntax.
access-list access-list-number remark remark
Context-Based Access Control
CBAC inspects traffic that travels through the firewall in order to discover and manage state information for TCP and UDP sessions. This state information is used in order to create temporary openings in the access lists of the firewall. Configure ip inspect lists in the direction of the flow of traffic initiation in order to allow return traffic and additional data connections for permissible session, sessions that originated from within the protected internal network, in order to do this.
Authentication Proxy
Authentication proxy is used to authenticate inbound or outbound users, or both. Users who are normally blocked by an ACL can bring up a browser to go through the firewall and authenticate on a TACACS+ or RADIUS server. The server passes additional ACL entries down to the router in order to allow the users through after authentication.
Turbo ACLs
Turbo ACLs are found only on the 7200, 7500, and other high-end platforms. The turbo ACL feature is designed in order to process ACLs more efficiently in order to improve router performance.
Use the access-list compiled command for turbo ACLs. This is an example of a compiled ACL.
access-list 101 permit tcp host 10.1.1.2 host 172.16.1.1 eq telnet
access-list 101 permit tcp host 10.1.1.2 host 172.16.1.1 eq ftp
access-list 101 permit udp host 10.1.1.2 host 172.16.1.1 eq syslog
access-list 101 permit udp host 10.1.1.2 host 172.16.1.1 eq tftp
access-list 101 permit udp host 10.1.1.2 host 172.16.1.1 eq ntp
After the standard or extended ACL is defined, use the global configuration command in order to compile.
!--- Tells the router to compile
access-list compiled
Interface Ethernet0/1
ip address 172.16.1.2 255.255.255.0
!--- Applies to the interface
ip access-group 101 in
The show access-list compiled command shows statistics about the ACL.
Distributed Time-Based ACLs
Distributed time-based ACLs were introduced order to implement time-based ACLs on VPN-enabled 7500 series routers.
Receive ACLs
Receive ACLs are used in order to increase security on Cisco 12000 routers by the protection of the gigabit route processor (GRP) of the router from unnecessary and potentially nefarious traffic.
Infrastructure Protection ACLs
Infrastructure ACLs are used in order to minimize the risk and effectiveness of direct infrastructure attack by the explicit permission of only authorized traffic to the infrastructure equipment while permitting all other transit traffic.
Transit ACLs
Transit ACLs are used in order to increase network security since they explicitly permit only required traffic into your network or networks.
Protocols with Access Lists Specified by Numbers
Protocol Range
| IP | 1 to 99 |
| Extended IP | 100 to 199 |
| Ethernet type code | 200 to 299 |
| Ethernet address | 700 to 799 |
| Transparent bridging (protocol type) | 200 to 299 |
| Transparent bridging (vendor code) | 700 to 799 |
| Extended transparent bridging | 1100 to 1199 |
| DECnet and extended DECnet | 300 to 399 |
| XNS | 400 to 499 |
| Extended XNS | 500 to 599 |
| AppleTalk | 600 to 699 |
| Source-route bridging (protocol type) | 200 to 299 |
| Source-route bridging (vendor code) | 700 to 799 |
| IPX | 800 to 899 |
| Extended IPX | 900 to 999 |
| IPX SAP | 1000 to 1099 |
| Standard VINES | 1 to 100 |
| Extended VINES | 101 to 200 |
| Simple VINES | 201 to 300 |
Текст взят с сайта cisco.com
Продолжаем тему ELRP
При внедрении скрипта оказалось, что существует 2 способа заставить порт рассылать elrp pdu.
Прописать elrp-client для всех портов в данном vlan (при этом свитч автоматически "увидит" все порты на которых есть vlan и автоматом начнет рассылку pdu с этих портов и, если добавить порты в vlan позже, они тоже будут участвовать в elrp).
configure elrp periodic vlan-xxx ports all interval 10 log-and-trap
Или прописать elrp-client только для определенных портов указывая их диапазоном или через запятую. НО при этом нельзя указать порт, который не состоит в данном vlan. Это вызовет ошибку. Очень хотелось бы видеть возможность задания не только диапазона all (1-50), но и отличных от него с автоопределением портов в данном vlan для заданного диапазона.
А пока пришлось написать скрипт, автоматизирующий это дело...
четверг, 7 октября 2010 г.
Борьба с петлями. ELRP.
Хочется избежать ситуаций, когда из-за нерадивого клиента ложится несколько свитчей в сети оператора. Даже если не ложится, все равно, петли - это плохо =)
Во всех коммутаторах серии summit, кроме 150-х, есть такая фича - UPM (Universal Port Management). Крайне полезная вещь, а если есть задатки программирования, то вообще можно горы свернуть. В общем почему-то Extreme предлагает при обнаружении в сети петли (с помощью протокола ELRP - Extreme Loop Recognition Protocol) блокировать ingress port. Иногда им становится uplink, что не очень хорошо и приводит к выпадению коммутатора из сети. Мы будем блокировать egress port. Тем самым отключая только клиента, который петляет.
Собственно скрипт взят с форума http://ethernation.net, спасибо dudekm. В задачу так же входила рассылка оповещений о петле. Реализовано это через EPICenter.
create log filter ELRP_Loop_Detect
# Создаем лог-фильтр для парсинга логов на предмет петли
create log filter ELRP_Disable_Alarm
# Лог-фильтр для отправки брошенных в консоль сообщений на EPICenter
configure log filter ELRP_Loop_Detect add events ELRP.Report.Message match string "LOOP DETECTED"
# кофигурим парсинг лога
configure log filter ELRP_Disable_Alarm add events UPM.Msg.exshLaunchStsFailLoop
configure log filter ELRP_Disable_Alarm add events System.userComment
# Конфигурим парсинг лога для отправки сообщений на эпицентр
create log target upm Disable_Looped_Port
enable log target upm Disable_Looped_Port
configure log target upm Disable_Looped_Port filter ELRP_Loop_Detect severity Info
configure log target upm Disable_Looped_Port match Any
# Создаем лог-таргет, кот. говорит, что при обнаружении в логе
# срабатываний по фильтру elrploop нужно запустить скрипт Disable_Looped_Port
create upm profile Disable_Looped_Port
disable port $EVENT.LOG_PARAM_7
create log entry "Port $EVENT.LOG_PARAM_7 disabled because of ELRP loop detected. Someday I will be the most powerlful jedi ever!"
# создаем скрипт, который выключает порт, посылает snmp trap и записывает инфу в лог
enable syslog
# включаем syslog
conf syslog add xx.xxx.xx.x:514 vr "VR-Mgmt" local0
# Добавлям syslog server
configure log target syslog xx.xxx.xx.x:514 vr VR-Mgmt local0 filter ELRP_Disable_Alarm severity Info
enable log target syslog xx.xxx.xx.x:514 vr VR-Mgmt local0
# "create log entry" создает запись в логе с severity = info, отправляем эту запись в эпицентр
enable elrp-client
включаем ELRP
Далее на сервере EPICentr настраиваем alarm, который, при получении от коммутатора через syslog сообщения с severity info, отправит e-mail на определенные адреса.
И вообще, syslog в скрипте используется как костыль для уведомления сервера EPICenter о срабатывании скрипта. Красивее конечно использовать snmp, но я пока не понял как на эпицентре ловить трап, созданный через create snmp trap
Во всех коммутаторах серии summit, кроме 150-х, есть такая фича - UPM (Universal Port Management). Крайне полезная вещь, а если есть задатки программирования, то вообще можно горы свернуть. В общем почему-то Extreme предлагает при обнаружении в сети петли (с помощью протокола ELRP - Extreme Loop Recognition Protocol) блокировать ingress port. Иногда им становится uplink, что не очень хорошо и приводит к выпадению коммутатора из сети. Мы будем блокировать egress port. Тем самым отключая только клиента, который петляет.
Собственно скрипт взят с форума http://ethernation.net, спасибо dudekm. В задачу так же входила рассылка оповещений о петле. Реализовано это через EPICenter.
create log filter ELRP_Loop_Detect
# Создаем лог-фильтр для парсинга логов на предмет петли
create log filter ELRP_Disable_Alarm
# Лог-фильтр для отправки брошенных в консоль сообщений на EPICenter
configure log filter ELRP_Loop_Detect add events ELRP.Report.Message match string "LOOP DETECTED"
# кофигурим парсинг лога
configure log filter ELRP_Disable_Alarm add events UPM.Msg.exshLaunchStsFailLoop
configure log filter ELRP_Disable_Alarm add events System.userComment
# Конфигурим парсинг лога для отправки сообщений на эпицентр
create log target upm Disable_Looped_Port
enable log target upm Disable_Looped_Port
configure log target upm Disable_Looped_Port filter ELRP_Loop_Detect severity Info
configure log target upm Disable_Looped_Port match Any
# Создаем лог-таргет, кот. говорит, что при обнаружении в логе
# срабатываний по фильтру elrploop нужно запустить скрипт Disable_Looped_Port
create upm profile Disable_Looped_Port
disable port $EVENT.LOG_PARAM_7
create snmp trap severity info event ELRP_Loop_Port_Disabled "Port $EVENT.LOG_PARAM_7 disabled because of ELRP loop detected."
create log entry "Port $EVENT.LOG_PARAM_7 disabled because of ELRP loop detected. Someday I will be the most powerlful jedi ever!"
# создаем скрипт, который выключает порт, посылает snmp trap и записывает инфу в лог
enable syslog
# включаем syslog
conf syslog add xx.xxx.xx.x:514 vr "VR-Mgmt" local0
# Добавлям syslog server
configure log target syslog xx.xxx.xx.x:514 vr VR-Mgmt local0 filter ELRP_Disable_Alarm severity Info
enable log target syslog xx.xxx.xx.x:514 vr VR-Mgmt local0
# "create log entry" создает запись в логе с severity = info, отправляем эту запись в эпицентр
enable elrp-client
включаем ELRP
Далее на сервере EPICentr настраиваем alarm, который, при получении от коммутатора через syslog сообщения с severity info, отправит e-mail на определенные адреса.
И вообще, syslog в скрипте используется как костыль для уведомления сервера EPICenter о срабатывании скрипта. Красивее конечно использовать snmp, но я пока не понял как на эпицентре ловить трап, созданный через create snmp trap
The Begining! =)
Буду здесь постить некоторые интересные вещи о продуктах компании Extreme Networks, с которыми приходится сталкиваться по ходу работы. Так, для себя, что бы не забыть
Подписаться на:
Сообщения (Atom)