ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
ip-as.ru :: Регистрация IP и Автономных систем
Subnets.ru ресурс компании ООО "Меганет-2003" mega-net.ru

Версия для печати Версия для печати

Архивные статьи в категории ‘Сетевое оборудование’

ЗАМЕТКА

В рамках поднятия IPTV в сети столкнулись с приставкой D-Link DIB-120.

Симптомы

Приставка D-Link DIB-120 при загрузке показывает логотип Alpha и потом черный экран и больше ничего.

Выяснилось

Компания Dlink завезла в Россию партию DIB-120, залитых безбраузерной прошивкой.
Отличить такую приставку можно по ее серийному номеру. Он начинается с Р1Т818.
В приставке прошит статический IP-адрес 192.168.1.1 и она слушает мультикаст группу с адреса 239.60.8.1:37732

Решение проблемы

Существуют два способа решения проблемы:

1. Если у вас есть сервер с OS Linux, то можно запустить вещание файла прошивки на  мультикаст адрес 239.60.8.1:37732 с помощью проги amfus.

Положите файлы прошивки и amfus в одну папку, затем создайте в этой же папке конфиг:

DIB120.conf:

a0_rootfs a-fs-cramfs.img V4.03.009 14299136 e6d0e447beed049bb2d41798721f29d7
kernel vmlinuz-7402c0 V4.03.009 1602656 7cc07013cc6ff0ea8f078920175791c1

Затем запустите:

./amfus -d DIB120.conf -m 239.60.8.1:37732 -i 1000 -t 32

2. Можно закачать прошивку с помощью HTTP сервера.  Как это сделать было описано в этой статье, процитирую ее:

По умолчанию IP STB D-Link DIB-120 поставляется без прошивки (при загрузке отображается ALPHA и черный экран).

На форумах говорят, что это «бракованная» партия, а на самом деле это «чистый» аппарат без странички.

Чтобы исправить это можно загрузить в него следующую прошивку 4.04.013_multicast.rar (доступна обновленная прошивка для DIB-120 от 6.11.09 4.05.004_multicast.rar).

Для перепрошивки понадобиться любой WEB сервер (например Apache).

В корневую директорию сервера необходимо сохранить два файла, которые находятся в архиве (a-fs-cramfs.img и vmlinuz-7402c0).

В качестве примера установлен IP сервера (компьютера с установленным Apache) – 192.168.1.2.

Устройство по умолчанию имеет IP 192.168.1.1, для этого в командной строке нужно выполнить команду telnet 192.168.1.1 на запрос имени пользователя необходимо указать root, а пароль пустой.

В командной строке DIB-120 нужно выполнить следующие команды:

cd /tmp

wget http://192.168.1.2/vmlinuz-7402c0
eraseall /dev/mtd2 ; dd if=vmlinuz-7402c0 of=/dev/mtd2

wget http://192.168.1.2/a-fs-cramfs.img
eraseall /dev/mtd0 ; dd if=a-fs-cramfs.img of=/dev/mtd0

reboot

Внимание! После перезагрузки пароль root’a будет изменен (см. файл password.txt в архиве), пароль можно изменить выполнив команду passwd

Оригинал статьи тут: http://cworld.org.ua/2009/09/16/firmware-d-link-dib-120/

Большое спасибо Hades за данную публикацию,  а то у меня FreeBSD и я уже чуть было не озадачился поднятием эмулятора Linux :)

Сделал все как описано в статье, за исключением того, что поднял не Apache, а по быстрому поставил  nginx (/usr/ports/www/nginx).

Все получилось, после прошивки и ребута приставка начала стучаться по DHCP и успешно получила от моего сервера DHCP IP-адрес.

Вот конфиг  nginx.conf:

user   www www;
worker_processes  1;

error_log  logs/error.log;
pid         /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;

    server {
        listen       192.168.1.2:80;
        server_name  localhost;

        location / {
            root   /usr/local/www/nginx;
            index  index.html index.htm;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/local/www/nginx-dist;
        }
    }
}

Уверен, что данная заметка пригодится не только мне.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Loading ... Loading ...
Отправить на почту Отправить на почту Версия для печати Версия для печати

IPIP tunnel Juniper MX-series Routers + static route via IPIP tunnel interface

Появилась тут задача прокинуть между Juniper и FreeBSD сервером IPIP туннель и пророутить через него подсеть IP-адресов.

Как водится начал с чтения документации:

Но как и в предыдущей статье толи я  тупой, толи лыжи не едут, толи они так пишут мануалы  :(

Расскажу как я решил сию «проблему» идя по своим «шагам», т.к. уверен. что не только я, а и кто-то ещё натолкнется на непонимание мануала и кучу, возникающих по мере чтения, вопросов, которые остаются без ответов.

Сначала возник вопрос: «а где взять необходимый интерфейс в джунике ?».

Читаю Tunnel Services Overview:

ipip
Internally generated IP-over-IP interface. This interface is generated by the JUNOS software to handle IP-over-IP encapsulation. It is not a configurable interface.

Смотрю есть ли у меня на джунипере такой. Да  есть, обнаружен интерфейс:

root@juniper> show interfaces ipip

Physical interface: ipip, Enabled, Physical link is Up
Interface index: 11, SNMP ifIndex: 9
Type: IPIP, Link-level type: IP-over-IP, MTU: Unlimited, Speed: Unlimited
Device flags   : Present Running
Interface flags: SNMP-Traps
Input packets : 0
Output packets: 0

Но меня очень напрягают слова «It is not a configurable interface«. Смотрю далее:

ip-0/0/0
Configurable IP-over-IP encapsulation (also called IP tunneling) interface. IP tunneling allows the encapsulation of one IP packet over another IP packet.

Вот это уже ближе, хотя бы указано, что он «Configurable«, но что делать если по show interfaces такого интерфейса нет ??? Блин, приплыли….

Решил попробовать все же отконфигурить интерфейс ipip. Конфигурю его так:
root@juniper# show interfaces ipip

unit 0 {
    tunnel {
        source XX.XX.XX.XX;
        destination YY.YY.YY.YY;
    }
    family inet {
        address 10.255.255.5/30;
    }
}

Где XX.XX.XX.XX это один из внешних IP-адресов джуника, YY.YY.YY.YY внешний IP-адрес FreeBSD сервера, а 10.255.255.5 IP-адрес на туннеле со стороны джунипера.

Коммитим конфигурацию на джунипере и идем на FreeBSD. Конфигуим её:

ifconfig gif0 create mtu 1480 link2 tunnel YY.YY.YY.YY  XX.XX.XX.XX 10.255.255.5 10.255.255.6 netmask 255.255.255.252

С IP-адресами все тоже самое, за исключением того, что ессно они «зеркальные», т.е. идут в другом порядке. 10.255.255.6 IP-адрес на туннеле со стороны FreeBSD.

После этого посмотрим создался ли туннель:
ifconfig gif0

gif0: flags=c051 mtu 1480
        tunnel inet YY.YY.YY.YY --> XX.XX.XX.XX
        inet 10.255.255.6 --> 10.255.255.5 netmask 0xfffffffc

Пробую попинговать с обеих сторон туннельные адреса (10.255.255.X) и результат успешен, с двух сторон пинг ходит.

«УРА !!! Задача решена и так просто !»  - подумал я, но не тут то было…….

Мне же необходимо выполнить вторую часть задачи, а именно пророутить через созданный туннель подсеть  IP-адресов.

Делаю это, добавляю мой статический маршут для подсети, которую я хочу роутить через туннель. Прописываю маршрут в секции routing-options static:

route ZZ.ZZ.ZZ.0/29 {
    next-hop 10.255.255.6;
    retain;
}

коммичу изменения и получаю не совсем ожидаемый результат :(

А именно, что с джунипера любой IP-адрес из пророученной подсети пингуется, а вот если пробовать попинговать этот же адрес снаружи, то получаем ответ от джунипера о недоступности сети.

Хм…. что за хрень ? Маршрут для подсети в таблице маршрутизации присутствует и по команде:

root@juniper> show route terse

маршрут виден….. Получается что джунипер отказывается роутить (форвардить) пакеты до этой подсети через себя. Почему ? Потому что ipip «It is not a configurable interface» ?

Лезу в гугл и нахожу похожую проблему: PFE-forwarded IPv6. Не смотря на то, что тут IPv6, а у меня вопрос по IPv4, ответ был найден:

Otherwise the ipip.0 tunnel is only from the RE, which can’t forward transit traffic.

Ну собственно так себя мой джуник и ведет, не форвардит транзитный трафик….

Но я не сдался, лезу снова курить мануалы….. Смотрю в пример «Example: Configuring Unicast Tunnels«:
Configure two unnumbered IP-IP tunnels:

[edit interfaces]
ip-0/3/0 {

    unit 0 {

        tunnel {
            source 192.168.4.18;
            destination 192.168.4.253;
        }

        family inet;
    }

    unit 1 {

        tunnel {
            source 192.168.4.18;
            destination 192.168.4.254;
        }

        family inet;
    }

}

To configure a numbered tunnel interface, include an address under family inet:

[edit interfaces]
ip-0/3/0 {
    unit 0 {
        tunnel {
            source 192.168.4.18;
            destination 192.168.4.253;
        }
        family inet {
            address 10.5.5.1/30;
        }
    }
    unit 1 {
        tunnel {
            source 192.168.4.18;
            destination 192.168.4.254;
        }
        family inet {
            address 10.6.6.100/30;
        }
    }
}

И снова задаюсь вопросом, а откуда они взяли интерфейс ip-0/3/0 ? Почему у них такой интерфейс есть,а у меня нет ! Ведь написано ж, что в MX-серии это встроено:

The MX-series routers support Dense Port Concentrators (DPCs) with built-in Ethernet ports and therefore do not support Tunnel Services PICs. To create tunnel interfaces on an MX-series router, you configure a DPC and the corresponding Packet Forwarding Engine to use for tunneling services at the [edit chassis] hierarchy level. You also configure the amount of bandwidth reserved for tunnel services. The JUNOS software creates tunnel interfaces on the Packet Forwarding Engine. To create tunnel interfaces on MX-series routers, include the following statements at the [edit chassis] hierarchy level

Так, получается, что я должен взять реальный интерфейс и настроить его для работы с tunneling services. Но стоп, у меня нет свободных интерфейсов, все что есть сейчас работают как Ethernet интерфейсы.

Возникает новый резонный вопрос,  а что будет если на отконфигуренном Ethernet интерфейсе добавить настройки и для tunneling services ?

Нашел ответ на этот вопрос вот тут:

The Packet Forwarding Engine of a 10-Gigabit Ethernet 4-port DPC supports either tunnel interfaces or Ethernet interfaces, but not both.

Мда…. опять приплыли… не может интерфейс быть и тунельным и эзернет интерфейсом :(

Неужели сделать то что мне надо невозможно если нет свободного физического интерфейса ?

М.б. меня не отпускали слова «встроенный», а м.б. остатки памяти напомнили текст предыдущей статьи, я не знаю, но полез я выполнять команду:

root@juniper> show chassis hardware

...........
FPC 5            REV 08   XXX-XXXXXX   KDXXXX            DPCE 4x 10GE R
...........
PIC 3                   BUILTIN      BUILTIN           1x 10GE(LAN/WAN)

Опа ! А это уже кое что. Встроенный интерфейс fpc 5 pic 3.
Такс… Снова возникает вопрос: «А м.б. именно этот интерфейс и поможет нам создать туннельный интерфейс ?»

Ответа на этот вопрос я так и не нашел, ни в мануалах, ни в гугле, но следуя тому что уже прочел в мануалах и банальной логике решил попробовать.

Для начала сношу все настройки с интерфейса ipip, который я конфигурил выше, затем приступаю к действиям по мануалу:

root@juniper# set chassis fpc 5 pic 3 tunnel-services bandwidth 10g

Получил в конфиге:
root@juniper# show chassis

fpc 5 {
    pic 3 {
        tunnel-services {
            bandwidth 10g;
        }
    }
}
network-services ip;

Так, интерфейс под tunnel services я задал, идем далее.

Попробую создать сам интерфейс:
root@juniper# set interfaces ip-5/3/0 unit 0

Ошибок эта команда не вызвала и интерфейс появился в конфиге. Значит я иду в правильном направлении.

Зададим IP-адреса, по которым и будет строится IPIP туннель:
root@juniper# set interfaces ip-5/3/0 unit 0 tunnel source XX.XX.XX.XX destination YY.YY.YY.YY

Теперь зададим IP-адрес на конце туннеля со стороны джунипера:
root@juniper# set interfaces ip-5/3/0 unit 0 family inet address 10.255.255.5/30

Смотрим что получилось:
root@juniper# show interfaces ip-5/3/0

unit 0 {
    tunnel {
        source XX.XX.XX.XX;
        destination YY.YY.YY.YY;
    }
    family inet {
        address 10.255.255.5/30;
    }
}

Выполняем заветную:
root@juniper# commit check
и получаю радостный для меня ответ:

configuration check succeeds

Ну вот вроде и все. Коммитим изменения и смотрим.

Вот теперь все работает как надо и поставленная задача полностью выполнена:

  • IPIP туннель между  Juniper и FreeBSD создан и работает
  • подсеть IP-адресов статически пророучена через туннель
  • джунипер  форвардит трафик до пророученной статическим маршрутом через IPIP туннель подсети

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Loading ... Loading ...
Отправить на почту Отправить на почту Версия для печати Версия для печати

С первого момента как я познакомился с оборудованием Juniper серии «M» я хотел попробовать фичу с логическими системами, т.е. создать роутер внутри роутера, но все как то руки не доходили. То времени не было, то свободной автономки с адресами.

И вот оно случилось, снова появилась свежеполученная AS с блоком адресов и я все же выкроил время для теста.

Пишу данный пост, что бы потом самому не забыть как это делалось, т.к. м.б. я тупой или жара так влияет на мозг человека, но как законектить основную систему с виртуальной я догнал не сразу, даже после того как «покурил» мануалы на juniper.net.

Дано

  • Juniper M7i
  • на нем уже поднят BGP с несколькими апстримами

Задача

Сделать виртуальный роутер (logical-system) внутри реального роутера, соединить их по протоколу BGP и проанонсировать новую ASку в Инет.

Connect Logical System BGP to Main system BGP.

Решение

Logical System Overview

Logical systems perform a subset of the actions of a physical router and have their own unique routing tables, interfaces, policies, and routing instances. A set of logical systems within a single router can handle the functions previously performed by several small routers.

The following are supported on logical systems:
Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), Routing Information Protocol (RIP), RIP next generation (RIPng), Border Gateway Protocol (BGP), Resource Reservation Protocol (RSVP), Label Distribution Protocol (LDP), static routes, various multicast protocols, and IP version 4 (IPv4) and version 6 (IPv6) are supported at the [edit logical-systems protocols] hierarchy level.
Basic Multiprotocol Label Switching (MPLS) for core provider router functionality is supported at the [edit logical-systems protocols mpls]] hierarchy level.
All policy-related statements available at the [edit policy-options] hierarchy level are supported at the [edit logical-systems policy-options] hierarchy level.
Most routing options statements available at the [edit routing-options] hierarchy level are supported at the [edit logical-systems routing-options] hierarchy level. Only the route-record statement is not supported at the [edit logical-systems routing-options] hierarchy level.
Graceful Routing Engine switchover (GRES) is supported.
You can assign most interface types to a logical system, including SONET interfaces, Ethernet interfaces, Asynchronous Transfer Mode (ATM) interfaces, ATM2 interfaces, Channelized Q Performance Processor (QPP) interfaces, aggregated interfaces, link services interfaces, and multilink services interfaces.
Source class usage, destination class usage, unicast reverse path forwarding, class of service, firewall filters, class-based forwarding, and policy-based accounting work with logical systems when you configure these features on the physical router.
Multicast protocols, such as Protocol Independent Multicast (PIM) and Distance Vector Multicast Routing Protocol (DVMRP) are supported at the [edit logical-systems logical-system-name protocols] hierarchy level. Rendezvous point (RP) and source designated router (DR) functionality for multicast protocols within a logical system is also supported.
The Bidirectional Forwarding Protocol (BFD) is supported.

The following restrictions apply to logical systems:
You can configure a maximum of 15 logical systems on one physical router.
The router has only one configuration file, which contains configuration information for the physical router and all associated logical systems. Master users can access the full configuration. However, logical system users can access only the portion of the configuration related to their particular logical system.
All configuration commits performed by a logical system user are treated as commit private. For more information on the commit private command, see the JUNOS System Basics Configuration Guide.
If a logical system experiences an interruption of its routing protocol process (rpd), the core dump output is saved in a file in the following location: /var/tmp/rpd_logical-system-name.core-tarball.number.tgz. Likewise, if you issue the restart routing command in a logical system, only the routing protocol process (rpd) for the logical system is restarted.
If you configure trace options for a logical system, the output log file is stored in the following location: /var/tmp/logical-system-name.
The following Physical Interface Cards (PICs) are not supported with logical systems: Adaptive Services PIC, ES PIC, Monitoring Services PIC, and Monitoring Services II PIC.
Sampling, port mirroring, IP Security (IPsec), and Generalized MPLS (GMPLS) are not supported.
Label-switched path (LSP) ping and traceroute for autonomous system (AS) number lookup are not supported.
If you configure multiple logical systems, you can configure a VPLS routing instance only for the first logical system configured at the [edit logical-systems logical-system-name routing-instances instance-name protocols vpls] hierarchy level.

Начинаем «курить» мануалы:

Более-менее понятно, что соединить осноной роутер (main) с виртуальным (logical-system) можно через интерфейсы. Но как ?

Читаем мануалы далее и выясняем, что сделать это можно или с помощью петли, т.е. тупо соединив проводом два физических порта  маршрутизатора (один порт будет принадлежать реальной системе, а второй порт виртуальной) или с помощью «Logical Tunnel Interface«.

Соединять с помощью провода между двумя реальными интерфейсами роутера я не мог, в виду отсутствия свободных, остается «логика»:

On M Series and T Series routers, logical tunnel interfaces allow you to connect logical systems, virtual routers, or VPN instances. The router must be equipped with a Tunnel Services PIC or an Adaptive Services Module (only available on M7i routers)

Такс и где же этот встроенный Tunnel Services PIC ?

А вот он:

root@juniper> show chassis hardware

FPC 1                                                    E-FPC
  PIC 2                   BUILTIN      BUILTIN           1x Tunnel

Что видно в интерфейсах:
root@juniper> show interfaces lt-1/2/0

Physical interface: lt-1/2/0, Enabled, Physical link is Up
  Interface index: 142, SNMP ifIndex: 191
  Type: Logical-tunnel, Link-level type: Logical-tunnel, MTU: Unlimited, Speed: 800mbps
  Device flags   : Present Running
  Interface flags: Point-To-Point SNMP-Traps
  Link flags     : None
  Physical info  : 13
  Current address: 00:1f:12:d5:a0:bc, Hardware address: 00:1f:12:d5:a0:bc
  Last flapped   : 2010-07-17 00:24:41 MSD (2w6d 10:13 ago)
  Input rate     : 3088 bps (4 pps)
  Output rate    : 3088 bps (3 pps)

Получается, что все что нам нужно для выполнения задачи присутствует.

Прочитав Configuring Logical Tunnel Interfaces меня напрягли слова:

To connect two logical systems, you configure a logical tunnel interface on both logical systems.

«Эмм…. две логические…..» подумал я, а как же быть если я собираюсь законектить не две логические системы, а логическую и реальную ?

Смотрю на картинку  в примере настройки (Example: Configuring Logical Systems) и вижу что опять же виртуальные роутеры соединяются с реальными, но нигде реальные роутеры не соединяются с виртуальнфми внутри себя. Так делать нельзя ? Хм… как минимум странно.

Зрим в пример туннельного интерфейса:

lt-fpc/pic/port {
     unit logical-unit-number {
          encapsulation encapsulation;
          peer-unit unit-number; # peering logical system unit number
          dlci dlci-number;
          family (inet | inet6 | iso | mpls);
    }
}

Хм…. вроде все понятно, а вроде и нет ? Что такое peer-unit и какой номер указывать ? Читаем о peer-unit:

Syntax
peer-unit unit-number;
Hierarchy Level
[edit interfaces interface-name unit logical-unit-number],
[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number]
Release Information

Statement introduced before JUNOS Release 7.4.
Description

Configure a peer relationship between two logical systems.
Options

unit-number—Peering logical system unit number.
Usage Guidelines

See Configuring Logical Tunnel Interfaces.
Required Privilege Level

interface—To view this statement in the configuration.

interface-control—To add this statement to the configuration

Стало понятнее ? Мне нет….

Дальнейшее «курение» мануалов просветления в этом вопросе не принесло. Практика, попытки сделать хоть что то, тоже. Все они заканчивались выводом разнообразных ошибок при коммите (commit), например:

peer-unit needs to be configured for logical tunnel interface
error: configuration check-out failed
encapsulation needs to be configured for logical tunnel interface
error: configuration check-out failed

Или о том что интерфейсы реальной системы пересекаются с виртуальной:

Interface lt-1/2/0.1 is also configured at the top-level
error: configuration check-out failed

Либо реальная система не видела виртуальную (не было пинга).

Ну что ж, обратимся к великому гуглу ! Но толи я не так искал, тли не так читал :) не знаю, но ответа на свой вопрос я по прежнему не получил.

Листая форум на juniper.net, а затем  повторное прочтение Configuring Logical Tunnel Interfaces навели меня на мысль о том, что нужно и в реальном (main) роутере и в виртуальном настраивать именно туннельный интерфейс и «натравливать» их друг на друга.

Ну что ж, попробуем. Начнем с интерфейсов.

Для начала создадим наш логический роутер (для примера имя ему дадим virtual-bgp-router), переходим в режим конфигурации и начинаем:

[edit]
root@juniper#
set logical-systems virtual-bgp-router

Затем создадим наш туннельный интерфейс, я возьму номер 999, вы ессно можете указать любой понравившийся вам номер юнита, которого ещё нет на этом интерфейсе:

[edit]
root@juniper#
set logical-systems virtual-bgp-router interfaces lt-1/2/0 unit 999

Зададим инкапсуляцию:

[edit]
root@juniper#
set logical-systems virtual-bgp-router interfaces lt-1/2/0 unit 999 encapsulation ethernet

Зададим с каким юнитом основного (main) роутера  мы будем соединяться:

[edit]
root@juniper#
set logical-systems virtual-bgp-router interfaces lt-1/2/0 unit 999 peer-unit 333

Добавим IP-адрес на интерфейс:

[edit]
root@juniper#
set logical-systems virtual-bgp-router interfaces lt-1/2/0 unit 999 family inet address 192.168.1.2/24

Так, с виртуалкой  пока закончили, теперь нужно реальному роутеру объяснить что к чему. Настроим туннельный  интерфейс и на нем.

[edit]
root@juniper#
set interfaces lt-1/2/0 unit 333

Создали  unit 333, тот юнит, который мы указали при создании туннельного интерфейса в логическом роутере, в кач-ве peer-unit.

Затем все действия точно такие же как делали выше, зададим инкапсуляцию:

[edit]
root@juniper#
set  interfaces lt-1/2/0 unit 333 encapsulation ethernet

Зададим с каким юнитом виртуального роутера мы будем соединяться:

[edit]
root@juniper#
set interfaces lt-1/2/0 unit 333 peer-unit 999

Добавим IP-адрес на интерфейс:

[edit]
root@juniper#
set interfaces lt-1/2/0 unit 333 family inet address 192.168.1.1/24

Ну вот, в первом приближении и все. Коммитим конфигурацию и смотрим, все ли работает как надо.

Для начала проверим есть ли у нас пинг с реального роутера на виртуальный:

[edit]
root@juniper#
run ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.910 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.802 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.839 ms
^C
— 192.168.1.2 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.802/0.850/0.910/0.045 ms

Затем наоборот, из виртуального на реальный:
[edit]
root@juniper#
run ping logical-system virtual-bgp-router 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.932 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.842 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.866 ms
^C
— 192.168.1.1 ping statistics —
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.842/0.880/0.932/0.038 ms

Пинг в наличии ! А значит и все остальное, по нашей задаче BGP пиринг между реальной системой и виртуальной, уже можно воплощать в жизнь.

Как поднимать BGP на Juniper в этой статье я расписывать не буду, т.к. уже делал это в статье «Настройка протокола BGP на оборудовании Juniper«, скажу лишь что в виртуальном роутере все настраивается точно так же как и в реальном, т.е. переходим в режиме редактирования в «ветку» своего виртуального роутера:

[edit]
root@juniper#
edit logical-systems virtual-bgp-router

Забываем о том, что это виртуалка и настраиваем так же как обычный роутер. Т.е. поехали:

[edit]
root@juniper#
set protocols bgp local-as 12345

где «12345″  есть наша свежеполученная AS, затем настраиваем BGP пир (создаем BGP соседа  192.168.1.1 (реальный роутер) и т.д. и т.п.

После того как вы закончите с настройкой протокола BGP на виртуальном роутере, не забудьте создать BGP соседа (192.168.1.2) и в реальном роутере.

По итогу получаем самое обычное взаимоотношение по протоколу BGP между реальным роутером и виртуальным ;)

Реальный роутер видит по BGP виртуальный и получает от него один свой префикс от новой ASки:
root@juniper> show bgp summary | match 192.168.1.2

192.168.1.2 12345 2629 77689 0 0 01:40:19 1/1/1/0 0/0/0/0

Ну и наборот, виртуальный видит реальный роутер, который сгружает ему full-view таблицу:
root@juniper> show bgp summary logical-system virtual-bgp-router

Groups: 1 Peers: 1 Down peers: 0

Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.1.1         54321      77697       2639       0       0    01:44:37 323070/323070/323070/0  0/0/0/0

З.Ы. Внутри виртуального роутера можно создавать и реальные интерфейсы этого роутера, таким образом вы можете связать виртуальный роутер с любой внешней железкой.

З.Ы.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 1, среднее: 2.00 из 5)
Loading ... Loading ...
Отправить на почту Отправить на почту Версия для печати Версия для печати

Нам недавно пришлось реализовывать «кабельный тестер» на PHP. В Инете нашлась статья, спасибо автору большое, которую я и приведу, прежде чем переходить к кодингу:

В коммутаторы DES-3526 и DES-3550 (возможно DES-3028 и DES-3052) встроен кабельный тестер который позволяет определять (уточнить точность измерений) длину кабеля.

Использование из CLI

Комманда не требует админских полномочий (повторяющиеся строки удалены):

DES3526:user#cable_diag ports 1-24
Command: cable_diag ports 1-24

Perform Cable Diagnostics ...

 Port   Type    Link Status            Test Result           Cable Length (M)
 ----  ------  -------------  -----------------------------  ----------------
  1     FE      Link Down      OK                             -
  2     FE      Link Down      No Cable                       -
...
  10    FE      Link Down      Pair1 Open      at 22  M       -
                               Pair2 Open      at 22  M
  11    FE      Link Down      Pair1 Open      at 25  M       -
                               Pair2 Open      at 25  M
  12    FE      Link Down      Pair1 Open      at 88  M       -
                               Pair2 Open      at 88  M
  14    FE      Link Up        OK                             40
  15    FE      Link Down      Pair1 Open      at 18  M       -
                               Pair2 Open      at 18  M
  16    FE      Link Up        OK                             69
  18    FE      Link Down      Pair1 Open      at 4   M       -
                               Pair2 Open      at 4   M
  19    FE      Link Up        OK                             34
  20    FE      Link Down      OK                             -
  21    FE      Link Up        OK                             40
  22    FE      Link Down      Pair1 Open      at 29  M       -
                               Pair2 Open      at 29  M
  24    FE      Link Down      Pair1 Open      at 22  M       -
                               Pair2 Open      at 22  M

Возможные значения:

  • Pair Open – обрыв на растоянии ХХ метров
  • Link Up, длинна ХХ метров
  • Link Down, OK – нельзя измерить длинну кабеля (но нагрузка есть)
  • Link Down, No Cable – нет кабеля

Описание OID-ов:

1.3.6.1.4.1.171.12.58.1.1.1.2 -
swEtherCableDiagPortType OBJECT-TYPE
  SYNTAX INTEGER {
    fastEthernet(0),
    gigaEthernet(1),
    other(2)
  }

# snmpwalk -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.2
SNMPv2-SMI::enterprises.171.12.58.1.1.1.2.1 = INTEGER: 0

SNMPv2-SMI::enterprises.171.12.58.1.1.1.2.25 = INTEGER: 1

SNMPv2-SMI::enterprises.171.12.58.1.1.1.2.26 = INTEGER: 1
Имеем, порты 1-24 поддерживают нужный функционал. Проверить состояние линков:

1.3.6.1.4.1.171.12.58.1.1.1.3 -
swEtherCableDiagLinkStatus OBJECT-TYPE
  SYNTAX INTEGER {
    link-down(0),
    link-up(1),
    other(2)
  }

# snmpwalk -v2c -c public 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.3

SNMPv2-SMI::enterprises.171.12.58.1.1.1.3.1 = INTEGER: 0

Все OID с результатом имеют валидные значения только после выполнения теста. Далее – OIDы для состояния пар:

  • 1.3.6.1.4.1.171.12.58.1.1.1.4 – cтатус первой пары
  • 1.3.6.1.4.1.171.12.58.1.1.1.5 – cтатус второй пары
  • 1.3.6.1.4.1.171.12.58.1.1.1.6 – cтатус третьей пары
  • 1.3.6.1.4.1.171.12.58.1.1.1.7 – cтатус четвертой пары

Возможные значения:

  • ok(0)
  • open(1)
  • short(2)
  • open-short(3)
  • crosstalk(4)
  • unknown(5)
  • count(6)
  • no-cable(7)
  • other(8)

И, соответственно, длины пар: 1.3.6.1.4.1.171.12.58.1.1.1.8 – длинна первой пары 1.3.6.1.4.1.171.12.58.1.1.1.11 – длинна четвертой пары OID, предназначенный для запуска теста:

1.3.6.1.4.1.171.12.58.1.1.1.12

Это единственный OID предназначенный как для чтения так и для записи.

  • action(1)
  • processing(2)
  • other(3)

Тестирование

Работа с кабельным тестером в целом совершенно стандартна (что есть несомненный плюс)

Общий подход:

  • Запустить тест (запись нужного значения в соответвующий OID
  • Дождаться завершения (проверить стением OID со статусом)
  • Считать интересующие значения.

Попробую проверить работу этой ф-и на портах с различными длинами и состоянием кабеля.

Линк есть, работающий абонент:

DES3526:user#cable_diag ports 21
Command: cable_diag ports 21

 Perform Cable Diagnostics ...

 Port   Type    Link Status            Test Result           Cable Length (M)
 ----  ------  -------------  -----------------------------  ----------------
  21    FE      Link Up        OK                             40

Запустить тест:

# snmpset -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.12.21 i 1

SNMPv2-SMI::enterprises.171.12.58.1.1.1.12.21 = INTEGER: 1

Проверить что он завершился (cтатус != 2):

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.12.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.12.21 = INTEGER: 3

Проверить состояние линка (1 – есть линк)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.3.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.3.21 = INTEGER: 1

Проверить состояние 1-й пары (0 – ОК)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.4.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.4.21 = INTEGER: 0

Проверить состояние 2-й пары (0 – ОК)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.5.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.5.21 = INTEGER: 0

Проверить состояние 3-й пары (8 – Нет кабеля, что естественно для 100-мбитного порта)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.6.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.6.21 = INTEGER: 8

Проверить состояние 4-й пары (8 – Нет кабеля, что естественно для 100-мбитного порта)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.7.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.7.21 = INTEGER: 8

Определить длинну 1-й пары (40 метров) # snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.8.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.9.21 = INTEGER: 40

Определить длинну 2-й пары (40 метров, что логично, т.к. пары одинаковые)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.9.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.9.21 = INTEGER: 40

Определить длинну 3-й пары (0 метров, фактически – не используется, не включена)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.10.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.10.21 = INTEGER: 0

Определить длинну 4-й пары (0 метров, фактически – не используется, не включена)

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.11.21

SNMPv2-SMI::enterprises.171.12.58.1.1.1.11.21 = INTEGER: 0

Кабель не подключен:

DES3526:user#cable_diag ports 2
Command: cable_diag ports 2
 Perform Cable Diagnostics ...

 Port   Type    Link Status            Test Result           Cable Length (M)
 ----  ------  -------------  -----------------------------  ----------------
  2     FE      Link Down      No Cable                       -

Запустить тест, убедиться что при запросе ответе – «нет кабеля» (8)

# snmpset -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.12.2 i 1

SNMPv2-SMI::enterprises.171.12.58.1.1.1.12.2 = INTEGER: 1

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.4.2

SNMPv2-SMI::enterprises.171.12.58.1.1.1.6.2 = INTEGER: 8

Кабель есть, отключен

Подключаю 2-х метровый патч-корд к коммутатору (второй конец висит в воздухе):

DES3526:user#cable_diag ports 2
Command: cable_diag ports 2

 Perform Cable Diagnostics ...

 Port   Type    Link Status            Test Result           Cable Length (M)
 ----  ------  -------------  -----------------------------  ----------------
  2     FE      Link Down      Pair1 Open      at 3   M       -
                               Pair2 Open      at 2   M

# snmpset -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.12.2 i 1

SNMPv2-SMI::enterprises.171.12.58.1.1.1.12.2 = INTEGER: 1

Кабель имеет статус open:

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.4.2

SNMPv2-SMI::enterprises.171.12.58.1.1.1.4.2 = INTEGER: 1

«Обрыв» (в реальности – просто конец кабеля) на расстоянии 3 метра по одной и 2 метра по другой паре.

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.8.2

SNMPv2-SMI::enterprises.171.12.58.1.1.1.8.2 = INTEGER: 3

# snmpget -v2c -c private 172.16.34.3 1.3.6.1.4.1.171.12.58.1.1.1.9.2

SNMPv2-SMI::enterprises.171.12.58.1.1.1.9.2 = INTEGER: 2

Насколько я могу судить, точности измерения вполне достаточня (плюс-минус метр).

Короткое на нескольких парах Сделал тестовый кабель с «коротким» на первой и третьей парах. Коммутатор показал правильные результаты для используемых пар:

DES3526:user#cable_diag ports 3
Command: cable_diag ports 3

 Perform Cable Diagnostics ...

 Port   Type    Link Status            Test Result           Cable Length (M)
 ----  ------  -------------  -----------------------------  ----------------
  3     FE      Link Down      Pair1 Short     at 3   M       -
                               Pair2 Open      at 3   M

При проверке через SNMP соответвующих OID результат такой же, останавливаться подробнее нет смысла.

Ссылка на оригинал статьи: http://wiki.sirmax.noname.com.ua/index.php/Dlink_Cable_Tester

Спасибо автору за труд, ну а мы перейдем к реализации этого безобразия на PHP.

PHP

Приведу простой пример, как все это может выглядеть на PHP.

Так как код в блоге выглядит не айс, то выкладываю файликом: http://subnets.ru/saved/dlink_cable_tester.php.txt

В моем рабочем варианте я ессно использую MySQL и все данные о свичах, OID`ах и значениях беру из БД.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Loading ... Loading ...
Отправить на почту Отправить на почту Версия для печати Версия для печати

Задача

Показывать график по трафику от/к одного BGP пира при условии того, что сессия с ним устанавливается в одном vlan с другими BGP сессиями до других BGP пиров.

Отрисовать график загрузки по интерфейсу не выход, т.к. помимо нужного трафика будет присутствовать еще и трафик с другими BGP пирами.

Решение

В недрах гугла нашлось упоминание про mac accounting.

Суть данной технологии  - ведение учета трафика в байтах и фреймах, ушедшего/пришедшего с определенного мак адреса.

Как по итогу оказалось сделать это нет так сложно.

Имеем Juniper M7i,  для включения на физическом интерфейсе достаточно сделать следующее:

Войдем в режим конфигурации:
root@juniper> configure

Добавим в конфигурацию:

[edit]
root@juniper#
set interfaces ge-0/0/1 gigether-options ethernet-switch-profile mac-learn-enable

после чего в конфигурации интерфейса появится новая секция, посмотрим:
[edit]
root@juniper.#
show interfaces ge-0/0/1

ge-0/0/1 {
    ...................
    gigether-options {
          ethernet-switch-profile {
                 mac-learn-enable;
          }
    }
    ....................
}

Перед коммитом проверим все ли в порядке:
[edit]
root@juniper#
commit check

Если все в порядке и ошибок нет, то можно применять:

[edit]
root@juniper#
commit comment «Enabling mac accounting»


Примечание:
mac accounting нельзя включить на встроенном гигабитном интерфейсе M7i и 10-портовом гигабитном контроллере.


На этом конфигурация Juniper закончена. Что дальше ? А дальше нам нужно как то получить данные для MRTG, те данные по которым и будет строиться график.
Это и оказалось сложнее всего, а именно нахождение необходимых OID’ов где можно забрать нужные нам данные.

Вот алгоритм их нахождения:

1. Получаем номер SNMP-индекса интерфейса (это может быть как сам физический интерфейс так и vlan (802.1q) на этом физическом интерфейсе), получаем на основе прописанного на интерфейсе IP-адреса, например 1.1.1.1 (в нашем случае IP-адрес находится на vlan):

.1.3.6.1.2.1.4.20.1.2.1.1.1.1 = INTEGER: 208

2. Получаем мак-адрес нужного нам BGP пира, например с IP-адресом 1.1.1.2, зная индекс интерфеса (исходя из п.1 это 208):

.1.3.6.1.2.1.4.22.1.2.208.1.1.1.2 = STRING: 0:e0:81:b6:3c:1b

Он нам понадобится далее, но в десятичном виде: 0.224.129.182.60.27

3. Теперь нам нужен номер vlan за которым находится BGP пир. Мы ессно его знаем исходя из конфига девайса и можем посмотреть так (зная номера его индекса исходя из п.1 это 208):

.1.3.6.1.2.1.2.2.1.2.208 = STRING: ge-0/0/1.994

Т.к. на физическом интерфейсе у нас действительно присутствует vlan с id 994 на котором висит IP-адрес 1.1.1.1.

4. после чего нам нужно будет получить SNMP-индекс физического ge-0/0/1, например вот так в тупую:

snmpwalk -v2c -c RO-Community JUNIPER_CONTROL_IP .1.3.6.1.2.1.2.2.1.2 | grep 'ge-0/0/1$'

Видим:

.1.3.6.1.2.1.2.2.1.2.180 = STRING: ge-0/0/1

5. И вот теперь, на основе всех полученных данных, мы можем составить финальные OID’ы для построение графика MRTG:

Первый OID это входящий трафик (HCInOctets):

.1.3.6.1.4.1.2636.3.23.1.1.1.3.180.994.0.224.129.182.60.27 = Counter64: 174250

Второй OID это исходящий трафик (HCOutOctets):

.1.3.6.1.4.1.2636.3.23.1.1.1.5.180.994.0.224.129.182.60.27 = Counter64: 86433120

После чего мы уже можем сделать конфиг для MRTG:

Title[peer_m7i]: 1.1.1.2 BGP peer
MaxBytes[peer_m7i]: 125000000
Target[peer_m7i]: .1.3.6.1.4.1.2636.3.23.1.1.1.3.180.994.0.224.129.182.60.27&.1.3.6.1.4.1.2636.3.23.1.1.1.5.180.994.0.224.129.182.60.27:RO-Community@JUNIPER_CONTROL_IP

З.Ы. На Juniper серии MX mac accounting включается немного по другому:

[edit]
protocols {
    l2-learning {
        mac-statistics;
    }
}

Ссылки

З.Ы.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Панфилов Алексей (lehis(at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 1, среднее: 5.00 из 5)
Loading ... Loading ...
Отправить на почту Отправить на почту Версия для печати Версия для печати

Задача

Ограничить клиента (блок IP адресов) по полосе на пограничном BGP маршутизаторе  Juniper M7i.

Готовых решений в интернете и в доках не нашел, скомпилировал свое на базе найденного и док.

Решение

Создаем полисер на нужную полосу пропускания (5Mbit в данном случае) и правила firewall`а для выделения нужной сетки по образцу:

http://www.juniper.net/techpubs/software/junos/junos42/swconfig-interfaces42/html/firewall-config18.html

получилось примерно так:

policer 5mp {
   if-exceeding {
      bandwidth-limit 5m;
      burst-size-limit 100k;
   }
   then discard;
}
family inet {
    filter lokalka-in {
        term 5mshape {
            from {
                source-address {
                    x.x.x.x/28;
                }
            }
            then policer 5mp;
        }
        term 5mshape2 {
            from {
                destination-address {
                    x.x.x.x/28;
                }
            }
            then policer 5mp;
        }
        term normal {
            then accept;
        }
    }

    filter lokalka-out {
        term 5mshape {
            from {
                destination-address {
                    x.x.x.x/28;
                }
            }
            then policer 5mp;
        }
        term 5mshape2 {
            from {
                source-address {
                    x.x.x.x/28;
                }
            }
            then policer 5mp;
        }
        term normal {
            then accept;
        }
    }
}

Добавил его на  смотрящий внутрь интерфейс Juniper`а :

ge-0/3/0 {
    vlan-tagging;
    unit 0 {
        vlan-id 1025;
        family inet {
            filter {
                    input lokalka-in;
                    output lokalka-in;
            }
            address myIPaddress/27;
        }
    }
}

Все :)

может быть можно сделать красивее,или менее напряжно для Juniper’a – коментарии приветсвуются.

Автор:  stalex

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 5.00 из 5)
Loading ... Loading ...
Отправить на почту Отправить на почту Версия для печати Версия для печати

Засада

Столкнулись тут с засадой на одном из серверов.

В сервер вставили дуальную карту Intel Gigabit ET Dual Port Server Adapter, сервер работает шлюзом.

pciconf -lv

igb0@pci0:4:0:0: card=0xa03c8086 chip=0×10c98086 rev=0×01 hdr=0×00
vendor = ‘Intel Corporation’
class = network
subclass = ethernet
igb1@pci0:4:0:1: card=0xa03c8086 chip=0×10c98086 rev=0×01 hdr=0×00
vendor = ‘Intel Corporation’
class = network
subclass = ethernet

Что получили ? А получили вместо ожидаемого улучшения, т.к. встроенные карточки похуже будут, тотальное ухудшение.

Если качать с самого сервера, то закачка идет в полную скорость канала (т.е. можно и более 20 МБ/с выжать),

а вот если качать как клиент (через этот сервер), то скорость закачки 50 килобайт и выше ну никак не идет :( ((((

Пробовали драйвера и самой FreeBSD 7.2 так и дрова от Yandex, так и дрова с официального сайта Intel.

Но ситуация не изменялась ни на грамм………

Чего мы тока не делали…… даже бубном стучали админским :) ничего не помогало, даже накатили сервер до  FreeBSD 7.3 PRERELEASE – результат тот же.

Трындец подумали мы……. но:

Сами понимаете, гуглили мы изрядно и вот появился луч надежды, наткнулись на описание той же проблемы на lists.freebsd.org, которая датируется аж:

Mon Jun 8 10:53:08 UTC 2009

Где человек пишет, что ему помогло. А именно:

в /etc/sysctl.conf пишем:

dev.igb.0.enable_lro=0
dev.igb.1.enable_lro=0
dev.igb.0.rx_processing_limit=2048
dev.igb.1.rx_processing_limit=2048

Затем перегружаем сервер, а не правим это налету через sysctl, а иначе не заработает, у нас не заработало, как чел и писал.

И вауля ! Сервер возвращается из ребута и наконец то  все становится как надо ! А именно получаем нормальную скорость через него как клиент.

Если по команде:

sysctl dev.igb.0.enable_lro=0
Вылезает:

sysctl: unknown oid ‘dev.igb.0.enable_lro’

Тогда попробуйте так:

ifconfig igb0 -lro

Итог:

  1. Драйвера с сайта Intel
  2. правка переменных sysctl

Ссылки:

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Авторы: Панфилов Алексей (lehis (at) subnets.ru), Николаев Дмитрий (virus (at) subnets.ru), Будимиров Максим (madmax (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 1, среднее: 5.00 из 5)
Loading ... Loading ...
Отправить на почту Отправить на почту Версия для печати Версия для печати

Дано:

  • маршрутизатор Cisco 2801, IOS 12.4(13)
  • приходит два канала Интернет от двух разных ISP

Необходимо организовать резервирование Интернет канала. Если живы оба провайдера, то выпускаем через ISP#1, соответственно, если ISP#1 упал, выходим через IPS#2.

Схема:

схема #1

Затем появилась ещё одна задача:

  • Выпустить в Интернет офис №2 и учесть резервирование

Новая схема:

схема #2

Конфигурация Cisco 1841:

!
track 123 ip sla 1 reachability
!
interface FastEthernet0/0
description ISP#1
ip address 85.0.0.242 255.255.255.248
ip nat outside
!
interface FastEthernet0/1
description ISP#2
ip address 84.0.0.242 255.255.255.248
ip nat outside
!
interface FastEthernet0/3/0
description OFFICE#1
switchport access vlan 10
!
interface FastEthernet0/3/1
switchport access vlan 20
!
interface FastEthernet0/3/2
switchport access vlan 30
!
!
interface Vlan10
description OFFICE#1
ip address 192.168.168.29 255.255.255.0
ip nat inside
!
interface Vlan20
description Link-to-Office#2-primary
ip address 192.168.0.2 255.255.255.248
ip nat inside
!
interface Vlan30
description Link-to-Office#2-backup
ip address 10.10.10.2 255.255.255.248
ip nat inside
!
ip local policy route-map LocalPolicy
ip route 0.0.0.0 0.0.0.0 85.0.0.241 track 123
ip route 0.0.0.0 0.0.0.0 84.0.0.241 254
!
ip nat inside source route-map ISP#1 interface FastEthernet0/0 overload
ip nat inside source route-map ISP#2 interface FastEthernet0/1 overload
!
ip sla 1
icmp-echo 85.0.0.241 source-interface FastEthernet0/0
timeout 1000
threshold 40
frequency 3
ip sla schedule 1 life forever start-time now
!
ip access-list extended PingISP#1
permit icmp host 85.0.0.242 host 85.0.0.241
!
access-list 104 remark OFFICE#1
access-list 104 permit ip 192.168.168.0 0.0.0.255 any
access-list 104 permit ip host 192.168.0.2 any
access-list 104 permit ip host 10.10.10.2 any
access-list 104 deny ip any any
!
route-map ISP#1 permit 10
match ip address 104
match interface FastEthernet0/0
!
route-map ISP#2 permit 10
match ip address 104
match interface FastEthernet0/1
!
route-map LocalPolicy permit 10
match ip address PingISP#1
set ip next-hop 85.0.0.241
set interface FastEthernet0/0
!

Конфигирация Cisco 870:

!
ip sla 1
icmp-echo 192.168.0.2 source-ip 192.168.0.4
timeout 1000
threshold 40
frequency 3
ip sla schedule 1 life forever start-time now
!
track 123 rtr 1 reachability
!
interface FastEthernet0
description Link-to-Office#1-primary
switchport access vlan 20
!
interface FastEthernet1
description Link-to-Office#1-backup
switchport access vlan 30
!
interface FastEthernet3
switchport access vlan 10
!
interface Vlan10
description OFFICE#2
ip address 192.168.123.29 255.255.255.0
!
interface Vlan20
ip address 192.168.0.4 255.255.255.248
!
interface Vlan30
ip address 10.10.10.4 255.255.255.248
!
ip route 0.0.0.0 0.0.0.0 192.168.0.2 track 123
ip route 0.0.0.0 0.0.0.0 10.10.10.2 254
!

Обсуждалось тут: subnets.ru/forum

Автор:  msergey

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 1, среднее: 5.00 из 5)
Loading ... Loading ...
Отправить на почту Отправить на почту Версия для печати Версия для печати

Коммутатор и Access Lists

Для фильтрации трафика коммутатор может использовать следующие типы ACL:

  • Router ACL
  • Port ACL
  • VLAN ACL
  • MAC ACL

Router ACL

Как и подразумевается в названии, Router ACL подобны на IOS ACL и используются для фильтрации сетевого трафика на SVI (интерфейсы SVI это Layer 3 на VLAN, физические Layer 3 интерфейсы и Layer 3 интерфейсы EtherChannel). Поддерживаются как стандартные, так и расширенные ACL. Для получения более детальной информации по Router ACL, обратитесь к соответствующей документации.

Port ACL

Port ACL подобны Router ACL, но работают на физических интерфейсах и интерфейсах Layer 2 коммутатора. Port ACL поддерживают фильтрацию только входящего трафика. Port ACL могут быть расширенного, стандартного и MAC-extended типа.

Обработка Port ACL подобна Router ACL: коммутатор проверяет ACL, назначенный данному интерфейсу и разрешает или блокирует пакет.

Когда ACL наложен на транковый порт, проверяется трафик всех проходящих через транк VLAN-ов – как данные, так и голос.

Основная прелесть Port ACL состоит в том, что может фильтроваться как IP трафик (используя IP access lists) так и non-IP трафик (используя MAC access list).

Внимание: Port ACLs не поддерживается на интерфейсах EtherChannel.

VLAN ACL (VACL)

VLAN ACL (так же известные как VLAN map) осуществляют пакетную фильтрацию всех типов трафика внутри VLAN или входящих/выходящих из него. В отличие от Router ACL, VACL не определяет направление трафика (input или output). Все пакеты находящиеся в VLAN (маршрутизируемые или внутренние) проверяются VACL. Для пакетной фильтрации в зависимости от направления трафика есть возможность использовать комбинацию VACL и Private VLAN.

VACL обрабатываются на аппаратном уровне, не оказывая влияния на производительность коммутатора. Производительность так же не зависит от объема VACL. Поэтому они упоминаются также как wire-speed ACL.

VACL на порту Layer 2

На рисунке ниже показана работа VACL на briged интерфейсе для Host A в VLAN 5 передающего данные на Host B в VLAN 10.

ns080402

VACL маршрутизируемом порту

На рисунке ниже показана работа IOS ACL и VACL на маршрутизируемом интерфейсе. Порядок выполнения определяется следующим образом:

1. VACL для input VLAN
2. Input IOS ACL
3. Output IOS AC
4. VACL для output VLAN

ns080403

Конфигурирование VACL

Для конфигурирования VACL (VLAN access map) необходимо выполнить следующие действия:

1. Определить стандартный или расширенный ACL, который будет использоваться на VACL.
2. Определить VLAN access map.
3. Описать критерий попадания
4. Описать выполняемое действие при попадании
5. Наложить VLAN access map на соответствующий VLAN.
6. Посмотреть, а что же у нас получилось?

В данном примере мы определяем и накладываем VACL, который будет отбрасывать пакеты, попадающие в access list 1 из сети 192.168.1.0/24, при этом все остальные пакеты, попадающие в access list 2 будут переданы. VACL применяется к VLAN-ам с 5 по 10.

Switch(config)#access-list 1 permit 192.168.1.0 0.0.0.255
Switch(config)#access-list 2 permit any
Switch(config)#vlan access-map mymap 10
Switch(config-access-map)#match ip address 1
Switch(config-access-map)#action drop
Switch(config-access-map)#exit
Switch(config)#vlan access-map mymap 20
Switch(config-access-map)#match ip address 2
Switch(config-access-map)#action forward
Switch(config-access-map)#exit
Switch(config)# vlan filter mymap vlan-list 5-10
Switch(config-access-map)#end

Switch# show vlan access-map
Vlan access-map «mymap» 10
Match clauses:
ip address: 1
Action:
drop
Vlan access-map «mymap» 20
Match clauses:
ip address: 2
Action:
Forward

Switch# show vlan filter
VLAN Map mymap is filtering VLANs:
5-10

MAC ACL

MAC ACL, также известный как Ethernet ACL предназначен для фильтрации non-IP трафика на VLAN или физических интерфейсах Layer 2 используя MAC адреса в именованном расширенном MAC extended ACL.

Шаги по конфигурации MAC ACL подобны обычным именованным расширенным ACL. MAC ACL могут применяться только для фильтрации входящего трафика.

Для определения MAC Extended ACL используется команда mac access-list extended.

После того, как MAC ACL будет создан, его необходимо наложить на интерфейс Layer 2 используя команду mac access-group [acl-name] in

В примере ниже мы покажем, как создать и применить MAC ACL для блокировки всех пакетов AppleTalk Address Resolution Protocol (AARP), пропуская отсальной трафик

Switch(config)# mac access-list extended my-mac-acl
Switch(config-ext-macl)# deny any any aarp
Switch(config-ext-macl)# permit any any
Switch(config-ext-macl)# exit
Switch(config)# interface Fastethernet0/10
Switch(config-if)# mac access-group my-mac-acl in
Switch(config-if)# end
Switch#

Оригинал:   http://dreamcatcher.ru/cisco/003_switches.html

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 2, среднее: 5.00 из 5)
Loading ... Loading ...
Отправить на почту Отправить на почту Версия для печати Версия для печати

Пишу заметочку себе, но м.б. кому нить ещё пригодится.

История

Сижу, конфигурю себе джуник, никого не трогаю :)

Закончил делать конфиг, выполняю:

virus@juniper# commit check

и… и получаю сей конфуз:

error: init: write failed: No space left on device
error: configuration check-out failed: daemon file propagation failed

или такой вариант конфуза:

virus@juniper# commit check

error: init: write failed: Unknown error: 0
error: init: write failed: No space left on device
error: write failure for file ttys
error: configuration check-out failed: daemon file propagation failed

Почесав репу :) полез смотреть, что же у меня там со свободным местом то происходит:

virus@juniper# run show system storage

Filesystem              Size       Used      Avail  Capacity   Mounted on
/dev/ad0s1a             885M       142M       672M       17%  /
devfs                   1.0K       1.0K         0B      100%  /dev
devfs                   1.0K       1.0K         0B      100%  /dev/
/dev/md0                 30M        30M         0B      100%  /packages/mnt/jbase
/dev/md1                179M       179M         0B      100%  /packages/mnt/jkernel-9.4R1.8
/dev/md2                 31M        31M         0B      100%  /packages/mnt/jpfe-M7i-9.4R1.8
/dev/md3                4.8M       4.8M         0B      100%  /packages/mnt/jdocs-9.4R1.8
/dev/md4                 48M        48M         0B      100%  /packages/mnt/jroute-9.4R1.8
/dev/md5                 32M        32M         0B      100%  /packages/mnt/jpfe-common-9.4R1.8
/dev/md6                2.0G       8.0K       1.8G        0%  /tmp
/dev/md7                2.0G       2.0G    -160.8M      109%  /mfs
/dev/ad0s1e              98M        26K        90M        0%  /config
procfs                  4.0K       4.0K         0B      100%  /proc
/dev/ad1s1f              34G       470M        31G        1%  /var

мдаааа…. подумал я, минус 160 метров это круто……

начал поиски, куда же все место подевалось ? и нашел таки куда:

virus@juniper# run file list detail /mfs/var/lpdfd/

/mfs/var/lpdfd/:
total 4120268
-rw-r-----  1 root  wheel      24576 May 7  12:16 __db.001
-rw-r-----  1 root  wheel      49152 May 7  12:16 __db.002
-rw-r-----  1 root  wheel     270336 May 7  12:16 __db.003
-rw-r-----  1 root  wheel    1146880 May 7  12:16 __db.004
-rw-r-----  1 root  wheel     475136 May 7  12:16 __db.005
-rw-r-----  1 root  wheel      49152 May 7  12:16 __db.006
-rw-r-----  1 root  wheel         25 May 7  12:17 __db.register
-rw-------  1 root  wheel          4 May 7  12:16 __db.rep.egen
-rw-------  1 root  wheel          4 May 7  12:16 __db.rep.gen
-rw-r-----  1 root  wheel   10485760 May 7  18:41 log.0000000001
-rw-r-----  1 root  wheel   10485760 May 8  01:15 log.0000000002
-rw-r-----  1 root  wheel   10485760 May 8  07:49 log.0000000003
-rw-r-----  1 root  wheel   10485760 May 8  14:23 log.0000000004
-rw-r-----  1 root  wheel   10485760 May 8  20:57 log.0000000005
-rw-r-----  1 root  wheel   10485760 May 9  03:31 log.0000000006
-rw-r-----  1 root  wheel   10485760 May 9  10:05 log.0000000007
-rw-r-----  1 root  wheel   10485760 May 9  16:39 log.0000000008
-rw-r-----  1 root  wheel   10485760 May 9  23:13 log.0000000009
-rw-r-----  1 root  wheel   10485760 May 10 05:47 log.0000000010
-rw-r-----  1 root  wheel   10485760 May 10 12:20 log.0000000011
-rw-r-----  1 root  wheel   10485760 May 10 18:54 log.0000000012
-rw-r-----  1 root  wheel   10485760 May 11 01:28 log.0000000013
-rw-r-----  1 root  wheel   10485760 May 11 08:02 log.0000000014
.................................................................
-rw-r-----  1 root  wheel   10485760 Jun 28 11:29 log.0000000190
-rw-r-----  1 root  wheel   10485760 Jun 28 18:03 log.0000000191
-rw-r-----  1 root  wheel   10485760 Jun 29 00:37 log.0000000192
-rw-r-----  1 root  wheel   10485760 Jun 29 07:11 log.0000000193
-rw-r-----  1 root  wheel   10485760 Jun 29 13:45 log.0000000194
-rw-r-----  1 root  wheel   10485760 Jun 29 20:19 log.0000000195
-rw-r-----  1 root  wheel   10485760 Jun 30 02:53 log.0000000196
-rw-r-----  1 root  wheel   10485760 Jun 30 09:26 log.0000000197
-rw-r-----  1 root  wheel   10485760 Jun 30 16:00 log.0000000198
-rw-r-----  1 root  wheel   10485760 Jun 30 22:34 log.0000000199
-rw-r-----  1 root  wheel   10485760 Jul 1  05:08 log.0000000200
-rw-r-----  1 root  wheel   10485760 Sep 17 15:53 log.0000000201
-rw-r-----  1 root  wheel     131072 May 7  12:16 lpdfd.db

Я ессно сократил вывод, иначе много места займет :) , вообщем файлов с log.0000000001 по log.0000000201 включительно.

Полез в Google, долго рылся в кучи всяких линков ниочем прежде чем найти всего одну путную ссылку, в которой чел рассказывал хоть о чем то похожем.

Почитал что люди пишут, посмотрел на версию софта на этом маршрутизаторе:

virus@juniper> show version

Hostname: juniper
Model: m7i
JUNOS Base OS boot [9.4R1.8]
JUNOS Base OS Software Suite [9.4R1.8]
JUNOS Kernel Software Suite [9.4R1.8]
JUNOS Packet Forwarding Engine Support (M/T Common) [9.4R1.8]
JUNOS Packet Forwarding Engine Support (M7i/M10i) [9.4R1.8]
JUNOS Online Documentation [9.4R1.8]
JUNOS Voice Services Container package [9.4R1.8]
JUNOS Services AACL Container package [9.4R1.8]
JUNOS Services LL-PDF Container package [9.4R1.8]
JUNOS AppId Services [9.4R1.8]
JUNOS IDP Services [9.4R1.8]
JUNOS Routing Software Suite [9.4R1.8]

пробуем удалить:
virus@juniper# run file delete /mfs/var/lpdfd/log.0000000201

и ессно хрен там:

rm: /mfs/var/lpdfd/log.0000000201: Permission denied

Стало понятно что я не удалю файлы из под своего аккаунта и нуна войти под root.

Консольный кабель подключен к COM порту и я полез через него, набрав в консоле, своей любимой OS FreeBSD, команду:
cu -l /dev/cuad0

Ну что ж, под root`ом я вошел, пробуем удалить файл снова:

root@juniper% cd /mfs/var/lpdfd/
root@juniper% rm log.0000000201

Отлично ! Файл спокойно удалился. Таким образом я потер все остальные файлы с логами, оставив тока с 10-к.

Смотрим что у нас там с местом ?

root@juniper% df -h

Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/ad0s1a    885M    142M    672M    17%    /
devfs          1.0K    1.0K      0B   100%    /dev
devfs          1.0K    1.0K      0B   100%    /dev/
/dev/md0        30M     30M      0B   100%    /packages/mnt/jbase
/dev/md1       179M    179M      0B   100%    /packages/mnt/jkernel-9.4R1.8
/dev/md2        31M     31M      0B   100%    /packages/mnt/jpfe-M7i-9.4R1.8
/dev/md3       4.8M    4.8M      0B   100%    /packages/mnt/jdocs-9.4R1.8
/dev/md4        48M     48M      0B   100%    /packages/mnt/jroute-9.4R1.8
/dev/md5        32M     32M      0B   100%    /packages/mnt/jpfe-common-9.4R1.8
/dev/md6       2.0G    8.0K    1.8G     0%    /tmp
/dev/md7       2.0G    100M    1.7G     5%    /mfs
/dev/ad0s1e     98M     26K     90M     0%    /config
procfs         4.0K    4.0K      0B   100%    /proc
/dev/ad1s1f     34G    470M     31G     1%    /var

С местом у нас теперь все путем ! Ну что ж, пробую откоммитить, для этого захожу в CLI:
root@juniper% cli
и чекаем конфиг:
root@juniper> commit check
и наконец получаем искомое:
configuration check succeeds

Ссылки

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 2, среднее: 4.50 из 5)
Loading ... Loading ...
Отправить на почту Отправить на почту Версия для печати Версия для печати