[ViacheslavR]

Суть проблемы такова имеется N пользовательских VLANов, имеется VLAN Serv в котором слушает pppoe mpd, на определенном сервере назовем его realay подняты процессы pppoe-relay с параметрами вида:

pppoe-relay -S Serv -C 1 -C 2 .... -C N

В какой-то момент пакеты которые ходят по части пользовательских vlan'ов начали приходить в другой причем уже внутри другого влана в направлении от релея к абоненту. Естественно mac адреса абонента в замусориваемом влане нет и в результате получается нехилый броадкаст по всему влану. При отключении релея в этот страдающий влан броадкаст прекращался. Что такое может быть?

Изменено 26 октября, 2010 пользователем ViacheslavR

[Frau]

такое может быть когда соеденинены 2 акцесных порта в разных виланах

[ViacheslavR]

и кстати засоряется этот влан только трафиком в направлении к клиенту, т.е. от релея к абоненту

[yakuzzza]

PPPoE-сервер должен быть включен во все Вланы пользователей. Классика жанра.

[ViacheslavR]

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

[yakuzzza]

Это как следствие. Не затыкайте дыры - делайте правильно.

[ViacheslavR]

а почему вы думаете что у нас не правильно?

сделано было так вполне из рациональных соображений отграничения броадкаста с пользовательских вланов от сервака, который не должен тратить свою производительность на обработку этих пакетов. Ну и по мелочи всякое. В конце концов нам так удобней. Тем не менее проблема явно не из-за архитектурных недостатков.

[Frau]

ищите петлю у себя, которая забриджевалась на доступе и через релей

[yakuzzza]

а почему вы думаете что у нас не правильно?

сделано было так вполне из рациональных соображений отграничения броадкаста с пользовательских вланов от сервака, который не должен тратить свою производительность на обработку этих пакетов. Ну и по мелочи всякое. В конце концов нам так удобней. Тем не менее проблема явно не из-за архитектурных недостатков.

Не спорю. Рассуждаю.

При правильном построении такая проблема в принципе отсутствует. Сеть работает более стабильно и прозрачно. Убирается лишнее колено. Броадкаст надо лимитить на портах абонентов или хотя бы на агрегации. Не думаю, что у вас в 1 широковещательном домене более 500 машин, хотя и это в свое время работало без проблем при вменяемом управлении и быстром отключении зараженных ПК.

А у вас из-за нелогичного и непрозрачного решения появилась или петля или баг в работе релея.

 

А дальше сами делайте выводы в архитектуре или нет проблемы.

Изменено 26 октября, 2010 пользователем yakuzzza

[ViacheslavR]

вот решил отписаться как была решена эта проблема:

1) Скачиваем исходники pppoe-relay с сайта http://www.roaringpenguin.com/products/pppoe

 

2) Внимательно изучив исходники обнаруживаем интересные вещи такие как хеш таблицы вида (клиент-RelaySessionID- SessionId -acPPPoE)

/* Session state for relay */
struct SessionHashStruct;
typedef struct SessionStruct {
    struct SessionStruct *next;    /* Free list link */
    struct SessionStruct *prev;    /* Free list link */
    struct SessionHashStruct *acHash; /* Hash bucket for AC MAC/Session */
    struct SessionHashStruct *clientHash; /* Hash bucket for client MAC/Session */
    unsigned int epoch;        /* Epoch when last activity was seen */
    UINT16_t sesNum;        /* Session number assigned by relay */
} PPPoESession;

/* Hash table entry to find sessions */
typedef struct SessionHashStruct {
    struct SessionHashStruct *next; /* Link in hash chain */
    struct SessionHashStruct *prev; /* Link in hash chain */
    struct SessionHashStruct *peer; /* Peer for this session */
    PPPoEInterface const *interface;    /* Interface */
    unsigned char peerMac[ETH_ALEN]; /* Peer's MAC address */
    UINT16_t sesNum;        /* Session number */
    PppoeSessionFunctionTable *ses;        /* Session data */
} SessionHash;

/* Function prototypes */

Итак значит при каждом запуске экземпляра pppoe-relay создается такой вот связный список в котором релей "помнит" об интерфейсе которому предназначен трафик маркированный SessionID. В моем случае трафик предназначенный для абонента одного вилана дублировался в другие, так как в списке создаваемом другим процессом мака для которого предназначен этот трафик не было и естественно в arp-таблице коммутатора этой записи тоже нет и поэтому он и отсылался на другие порты (аплинки в том числе).

Решением может послужить указание всех пользовательских интерфейсов с которых нужен релей в одном процессе, чтобы в системе присутствовал один хеш-список.

3) В исходниках релея находим запись #define MAX_INTERFACES 8 и изменяем её на нужное вам количество прослушиваемых интерфейсов (указываемых в параметрах запуска pppoe-relay)

4) Собираем

5) Используем