סיבים PON של IBC\HOT סאגת הVLAN ID

[itfan]

הפתרון ש-sys_admin נתן והפתרון של itfan - שניהם אותו פתרון.

...

לא בדיוק. ההבדל הוא במה ש-sys_admin כינה "דבר שני" שזה כל הסיפור (המיותר) של הגדרת VLAN filtering על הגשר br-wan. זה משהו שאפשר לעשות, אם רוצים (כמו שאפשר לעשות עוד הרבה מאוד שינויי הגדרות מיותרים), אבל לצורך מה שמדובר כאן, עדיף להימנע ממנו.

[DanielGR]

עוד מאמץ קטן לברר את הסוגיה עד הסוף:

Br-wan מוגדר בדגם הזה כברירת מחדל, כאשר מאפסים את ההגדרות - br-wan קיים. את הגדרת ה-pppoe אם קיים - מחילים על br-wan ולא על הפורט הפיזי (יש שניים). באופן הזה ניתן לחבר או את פורט ה-SFP או את פורט ה-Ethernet (לא בו זמנית) בלי צורך לשנות את ההגדרות. לכן לכאורה יש הגיון מסוים להחיל את הגדרת ה-VLAN ברמת ה-Bridge ולא ברמת הפורט הפיזי. זו הסיבה ש-br-wan קיים ומוגדר בדגם הזה.

מדוע לא בעצם? (בהינתן האמור לעיל והתוצאה הסופית שזהה פונקציונלית)

[itfan]

מדוע לא בעצם?

...

מי אמר שלא? זה בדיוק מה שמוצע כאן: להגדיר VLAN device עם מספר 601 ע"ג הגשר הקיים br-wan (הוא יקבל את השם br-wan.601)
ואז לערוך את ה-WAN interface ולהחליף בו את ה-Device מ-br-wan ל-br-wan.601 (ואם צריך גם את ה-Protocol מ-PPPoE ל-DHCP).

ההוראות לביצוע Step-by-Step Configuration שג'מיני ניפק מכסות גם את המקרה שבו ה-WAN מוגדר מלכתחילה על פורט יחיד (בלי ברידג'), אבל במקרה שבו חיבור ה-WAN מוגדר מלכתחילה דרך ברידג', זה בהחלט נשאר ככה.

[sys_admin]

מי שמתעקש לכתוב פה שטויות וכנראה "לא מבין את העבודה של OpenWRT עם נושא של VLANs” זה אתה. לצורך מה שנדרש פה, דהיינו חיבור ה-WAN ע"ג VLAN 601, אין שום תועלת ובטח לא צורך בלקנפג VLAN filtering על br-wan. כפי שג’מיני כנראה יודע, ומומלץ לך ללמוד ממנו, זה לא משנה אם ה-base device הוא פורט יחיד כמו eth0 או ברידג’ כמו br-wan (שיכול לכלול פורט אחד או יותר): הדבר הפשוט והמומלץ ביותר לצורך מה שנדרש כאן זה לקנפג את ה-VLAN device ע"ג ה-base device ואז לקנפג את חיבור ה-WAN ע"ג ה-VLAN device. וזהו! VLAN filtering זה מנגנון שנועד לחסום תעבורה (חוץ מתעבורה שדואגים לאפשר בעזרת הגדרות נוספות) ולצורך מה שנדרש פה, אין בזה שום תועלת. במקרה הטוב, מדובר בתוספת הגדרות מיותרות. במקרה הפחות טוב, זה יחסום דברים שעדיף שלא יחסמו.
זה תיאור מדויק למדי של מה שאתה עושה פה. על זה נאמר, הפוסל במומו פוסל.
בזה אתה לשם שינוי צודק, אבל לא באמת שאלת את השאלה הנכונה...

...

לא מובן למה אתה מתעקש להמשיך לכתוב שטויות מופרכות ולהתבזות כל פעם מחדש בהקשר לדברים הכי פשוטים ובסיסיים.
הרי, אם לפחות היית לומד לשאול את AI שאלות ממוקדות, היית חוסך את זה מעצמך.

הרי זה גם מובן מעליו שללא סינון מלא של תעבורת VLAN, מנגנון כזה של DSA שמיושם ב OpenWRT בשנים אחרונות לא יכול לעבוד בצורה תקינה עם תקשורת מתויגת VLAN.

[DanielGR]

נראה שאין תמימות דעים על הנושא?

יש הבדל בין ״נדרש״ ל-“מומלץ״

[sys_admin]

למי שבאמת מודע איך שהנתונים עוברים בתוך המנגנון של DSA, ברגע שהוא קיים במערכת שבשימוש, אז יש לו תמימות דעים על הנושא, למה זה כן נדרש ומה ההשלכות והתוצאות במקרה ההפוך.
וזה גם לא דבר חדש או ייחודי.

[tolaat01]

למי שבאמת מודע איך שהנתונים עוברים בתוך המנגנון של DSA, ברגע שהוא קיים במערכת שבשימוש, אז יש לו תמימות דעים על הנושא, למה זה כן נדרש ומה ההשלכות והתוצאות במקרה ההפוך.
וזה גם לא דבר חדש או ייחודי.

...

בפועל נחכה למישהו שיתחבר להוט וינסה - בינתיים יש שתי דרכים .
כמו בשיר חנהלה התבלבלה
נשאל אותו מאיפה בא

[sys_admin]

בפועל נחכה למישהו שיתחבר להוט וינסה - בינתיים יש שתי דרכים .
כמו בשיר חנהלה התבלבלה
נשאל אותו מאיפה בא

...

כמו שכבר כתבתי, אין אפילו שום צורך לחכות לאף אחד שיתחבר להוט, וכל אחד, מי שרוצה וזה מעניין אותו, יכול לגמרי לבד לנסות את זה, גם ללא שום חיבור להוט. בדיוק כפי שאני עשיתי את זה והסברתי גם איך. וגם לראות, מה קורה עם זליגה של הנתונים וגם עם משאבי חומרה וגם עם דברים אחרים, אם הולכים בדרך לא דרך.
כך, שחבל מאוד שחנהלה התבלבלה

[whatevernevermind]

נראה ששתי התשובות אמורות לעבוד, התשובה הראשונה דווקא יותר קרובה למה שבאמת "נכון" במקרה זה - בגלל שה-WAN משוייך לפורט פיזי אחד ואין משמעות לbridge בעל פורט לוגי בודד, הגישה המועדפת היא לא להשתמש כלל בbr-wan אלא להגדיר VLAN על הפורט הפיזי של הWAN (נניח eth0.601); את כל יתר הפורטים להגדיר על br-lan ללא VLAN. כך יש bridge רק בין פורטים שבאמת צריכים bridge (רמה 2) והניתוב IP מתבצע בנפרד לחלוטין (רמה 3) מול ממשק WAN שבכלל לא משתתף בbridge.

מה שכתבתי מומלץ רק למצב כזה. זה לא בהכרח מומלץ אם יש "עוד" דברים על הפורט הפיזי של הWAN, כמו עוד VLANים או בעבור router on a stick (עם IPoE, דווקא עם PPPoE שממילא רץ על המעבד הראשי, עדיף שוב לא לערב bridge נוסף ומיותר).

הפתרון הכי טוב זה שבכלל HOT יבקשו מIBC שישנו רוחבית את הפרופיל עבור הGF25 וONTים אחרים נתמכים כדי שיקלף בעצמו את הS-VLAN לפני שמעביר לפורט הנחושת של הלקוח ויוסיף אותו בכיוון השני, אבל אין להם שום אינטרס לעשות את זה...

[sys_admin]

אוי ואבוי, וזה עוד אחרי כל ההסברים הפשוטים של למה ממש לא ולמה כן נדרש בהקשר זה שימוש ב bridge .

[Jabberwock]

ב-Flint 2 אין Bridge WAN ולא נתקלתי בזה. למה הוא משמש?

[sys_admin]

הוא משמש להרבה דברים, אם צריכים משהו מהם, אבל, בהקשר זה, משמש ליצירת ממשק מתויג תקין. יכול לשמש גם למשל ל VLAN Trunk, אבל זה מקרה אחר.
בצד של LAN, הוא משמש בין היתר גם לאפשרויות של עם ה VLANs. בדיוק כמו שלפני שנים רבות, ב OpenWRT לצורך זה השתמשו בניהול מתג, שהיה בו.

[shilo]

הפתרון הכי טוב זה שבכלל HOT יבקשו מIBC שישנו רוחבית את הפרופיל עבור הGF25 וONTים אחרים נתמכים כדי שיקלף בעצמו את הS-VLAN לפני שמעביר לפורט הנחושת של הלקוח ויוסיף אותו בכיוון השני, אבל אין להם שום אינטרס לעשות את זה...

...

זה כבר מוגדר כך.
ל-99 אחוז מהלקוחות אין צורך לבצע שום הגדרה מיוחדת.
אם לקוח צריך להגדיר vlan 601 בשביל לגלוש - זו תקלה במנוי מהצד של IBC ורק IBC יכולים לפתור את זה.

אבל כפי שכתבתי, בגלל שזו תקלה כל כך נדירה - אין הרבה אנשים ב-IBC שיודעים איך לפתור אותה. למרות שהפתרון מבחינתם הוא די פשוט.

[whatevernevermind]

אוי ואבוי, וזה עוד אחרי כל ההסברים הפשוטים של למה ממש לא ולמה כן נדרש בהקשר זה שימוש ב bridge .

...

אוי ואבוי, בבקשה אל תטעה את הפורום. אין שום החלטת מיתוג רמה 2 שנדרשת פה ואין המרה בין מדיה אחת לאחרת. גם לא כדי לגשת לממשק ניהול של הGF25C. לא צריך, ולהיפך - לא מומלץ DSA במצבים בהם אין בכלל צורך בswitching. לא צריך VLAN-aware bridge כשבכלל לא צריך bridge (פורט לוגי בודד - תחזור להגדרה של מה זה bridge). במקרה הנוכחי לא מאבדים שום ביצועים אלא להיפך - גם במקרה של מיתוג תוכנתי וגם במקרה של מיתוג חומרתי (מיתוג=רמה2, ניתוב=רמה3).

[whatevernevermind]

זה כבר מוגדר כך.
ל-99 אחוז מהלקוחות אין צורך לבצע שום הגדרה מיוחדת.
אם לקוח צריך להגדיר vlan 601 בשביל לגלוש - זו תקלה במנוי מהצד של IBC ורק IBC יכולים לפתור את זה.
אבל כפי שכתבתי, בגלל שזו תקלה כל כך נדירה - אין הרבה אנשים ב-IBC שיודעים איך לפתור אותה. למרות שהפתרון מבחינתם הוא די פשוט.

...

אם הלקוח רואה או צריך בעצמו להוסיף VLAN אז זה לא מה שמוגדר לו... זו הגדרת MIB ב ME 171 == ExtVlanTagOperCfgData. אני לא מחובר לHOT אבל אם מישהו שרואה VLAN בצד הלקוח יסתכל בME 171 + 84, הוא אמור לראות שאין הוראה שנשלחה מהOMCI של IBC (כמעט תמיד ISAM של נוקיה, אישית באיזור המרכז עוד לא נתקלתי אצלם בDASAN או משהו אחר). ההוראה הנכונה היתה מגדירה לONT שאצל הלקוח לקלף/להוסיף תג במעבר אל/מ פורט הנחושת.

מסכים שכנראה 99% מהלקוחות לא משתמשים בציוד פרטי כלל, ושכל זה נחסך מהם, ואחרים משתמשים במשהו שמעלים את התג הנכנס ממילא כברירת מחדל (הרבה כרטיסי רשת ביתיים בווינדוס).

[itfan]

אוי ואבוי, וזה עוד אחרי כל ההסברים הפשוטים של למה ממש לא ולמה כן נדרש בהקשר זה שימוש ב bridge .

...

השטות המגוחכת הזאת שאתה מתעקש לחזור עליה עוד ועוד ועוד היא כמו להגיד שאף אחד לא יוכל להיכנס לאולם קולנוע אם לא ישימו בדלת שלו סדרן שיבדוק שלנכנסים יש כרטיס. התפקיד של הסדרן הוא למנוע כניסה של מי שלא אמור להיכנס. הוא לא הכרחי בשביל שאנשים יצליחו לעבור בדלת (שזה מה שאתה טוען שוב ושוב ושוב…).

יש במערכות מבוססות Linux שיטה בסיסית, ידועה ותיקה וברורה, איך לבצע חיבור רשת על גבי VLAN במקום חיבור לא מתויג: מגדירים VLAN device (עם המספר הנדרש) ש"יושב" על ה-base device הלא מתויג ואז מקנפגים את חיבור ה-IP (שיכול להיות מבוסס על DHCP או על כתובות סטאטיות או על PPPoE) על גבי אותו ה-VLAN device. זה לא משנה אם מדובר על חיבור מחשב שולחני עם כרטיס רשת יחיד או על חיבור פורט WAN של נתב. כמו ש-@whatevernevermind כתב נכון, זו "הגישה המועדפת.” זה משהו שיצא לי לקנפג מאות פעמים, גם בגרסאות שונות של OpenWrt, גם ב-RouterOS וגם בהתקנות של Debian ו-Ubuntu. זה גם, כמובן, מה שמתבצע "מאחורי הקלעים" בנתבים ביתיים שמצוידים בממשק ידידותי לקינפוג חיבור ה-WAN ע"ג VLAN, כמו הנתבים של חברת GL.iNet, למשל, וזה בדיוק מה שהוצע ע"י ג’מיני בפוסט הבא:
viewtopic.php?p=3402472#p3402472+
בתגובה לבקשה המאוד קונקרטית:
provide steps to configure the DHCP WAN connection in OpenWrt over VLAN 601 using Luci
על הדבר המאוד בסיסי וסטנדרטי הזה, אתה כתבת את השטות

שאם מיישמים את הפעולות אלה שקיבלת מ AI, אז כל מה שמקבלים במקרה זה, זה חוסר קישוריות מצד האינטרנט.

...

אם היית טורח לקנפג ולנסות את מה שהוצע לפני שאתה מכריז בשחצנות ש-"כל מה שמקבלים במקרה זה, זה חוסר קישוריות מצד האינטרנט," אז, מן הסתם, היית מגלה שדווקא יש במקרה הזה קישוריות וחוסך לעצמך ולכולנו את רוב הדיון המגוחך כאן. זה לא היה מפריע לך לטעון שעדיף לעשות דברים באופן מסובך יותר (מה שכנראה תואם את ההעדפות שלך גם בתחומים אחרים), אבל לפחות היה נוצר בסיס לדיון רציונלי במקום שתכתוב עוד ועוד שטויות שעלולות להטעות אנשים (ובטח לא מוסיפות לך כבוד).

ב-Flint 2 אין Bridge WAN ולא נתקלתי בזה. למה הוא משמש?

...

כמו ש-@DanielGR הסביר, הגשר br-wan ב-BPI-R3 מאפשר בחירה ומעבר חפשי בין פורט SFP לפורט RJ45 בחיבור ה-WAN, בלי שנדרש לשנות את הקונפיגורציה של המכשיר. לא אמורים לחבר את שני הפורטים בו זמנית ואם רוצים להשתמש בשניהם, אז כמו ש-@whatevernevermind כתב, מומלץ לפרק את הגשר: אם רוצים לממש dual-WAN, לרוב עדיף לעשות את זה עם שני פורטים נפרדים שלא מקושרים בגשר ואם יש חיבור WAN יחיד, אז לרוב כדאי לפרק את הגשר בשביל לצרף את אחד הפורטים ל-LAN.

[DanielGR]

קראתי שוב ושוב את הפוסטים על מנת לראות את ההבדל בין הגישות. להלן הפירוט:

התיאור שרשם @itfan הוא מדויק, השלב שבו יש הבדל בין שתי הגישות הוא זה:

Base device: Select the physical interface connected to your modem (usually eth0 or eth1 or br-wan)

וכאן יש הבדל האם משתמשים בפורט פיזי או ב- Bridge, ואפשר גם וגם. במידה ומשתמשים בפורט פיזי - ככה אכן זה עובד וידוע.

במידה והפורט הפיזי הוא חלק מ-Bridge, בדוגמא הזו br-wan, אז יש כביכול שכבה נוספת בין הפורט הפיזי והמעבד (כך אפשר לדמות את זה), ואז צריך על אותו ברידג' להגדיר vlan-filtering אחרת המעבד לא יראה את ה-traffic, ואם הבנתי נכון - זה מה ש- @sysadmin טוען.

לא בדקתי מה קורה אם מגדירים את ה-Base device כברידג', ולא מגדירים vlan filtering, אבל יש מידה מסוימת של הגיון בטענה שזה לא יעבוד.

מתי להשתמש בברידג' ומתי לא זה דיון נפרד, ובדוגמא הזאת כל עוד מגדירים נכון אפשר להשתמש ואפשר שלא.

[shilo]

אם הלקוח רואה או צריך בעצמו להוסיף VLAN אז זה לא מה שמוגדר לו... זו הגדרת MIB ב ME 171 == ExtVlanTagOperCfgData. אני לא מחובר לHOT אבל אם מישהו שרואה VLAN בצד הלקוח יסתכל בME 171 + 84, הוא אמור לראות שאין הוראה שנשלחה מהOMCI של IBC (כמעט תמיד ISAM של נוקיה, אישית באיזור המרכז עוד לא נתקלתי אצלם בDASAN או משהו אחר). ההוראה הנכונה היתה מגדירה לONT שאצל הלקוח לקלף/להוסיף תג במעבר אל/מ פורט הנחושת.
מסכים שכנראה 99% מהלקוחות לא משתמשים בציוד פרטי כלל, ושכל זה נחסך מהם, ואחרים משתמשים במשהו שמעלים את התג הנכנס ממילא כברירת מחדל (הרבה כרטיסי רשת ביתיים בווינדוס).

...

נראה לי שאנחנו בעצם מתארים את אותו דבר משתי זוויות שונות.

כשכתבתי שזה כבר מוגדר כך, הכוונה היתה שבמצב תקין בפרופיל הזה הלקוח לא אמור לראות את ה-VLAN בכלל.
לכן אם לקוח חייב להגדיר VLAN 601 בנתב שלו כדי לקבל DHCP, מבחינתי זה סימן שהמנוי לא קיבל את הפרופיל הנכון מצד IBC.

לגבי ה-99% - התכוונתי ללקוחות עם ציוד פרטי. פשוט הקהל הזה הרבה יותר נוכח בפורומים וקבוצות רשתות, אז כשיש תקלה כזאת שומעים עליה הרבה יותר ביחס לשכיחות שלה בפועל.

ובנוגע לתשתית עצמה - ממה שאני מכיר, באזור המרכז יש גם לא מעט אזורי DASAN, לא רק Nokia.

[itfan]

וכאן יש הבדל האם משתמשים בפורט פיזי או ב- Bridge, ואפשר גם וגם. במידה ומשתמשים בפורט פיזי - ככה אכן זה עובד וידוע.

...

וגם אם משתמשים ב-Bridge זה עובד בדיוק באותו אופן.

במידה והפורט הפיזי הוא חלק מ-Bridge, בדוגמא הזו br-wan, אז יש כביכול שכבה נוספת בין הפורט הפיזי והמעבד (כך אפשר לדמות את זה), ואז צריך על אותו ברידג' להגדיר vlan-filtering אחרת המעבד לא יראה את ה-traffic

...

זה לא נכון. כמו שכבר כתבתי, VLAN filtering זה מנגנון שחוסם תעבורה (כמו סדרן שבודק כרטיסים בכניסה לאולם). זה נדרש אם רוצים לדאוג לכך שלא כל VLAN יוכל להגיע לכל פורט ו/או אם רוצים לשנות תיוג של תעבורה (לקלף תגים, להוסיף תגים או להחליף תגים). Bridge בלי VLAN filtering זה כמו מתג לא מנוהל שפשוט מעביר את כל התנועה בלי לבדוק את התיוג ובלי לשנות אותו בשום צורה.

לא בדקתי מה קורה אם מגדירים את ה-Base device כברידג', ולא מגדירים vlan filtering,

...

אני כן בדקתי (הרבה פעמים ועל כל מיני מערכות). לדעתי, יהיה נחמד אם תבדוק בעצמך ותעזור להשאיר את הסאגה הזו מאחור.

אבל יש מידה מסוימת של הגיון בטענה שזה לא יעבוד.

...

מומלץ שפשוט תנסה ותראה. זה נחמד שאתה מנסה למצוא הגיון בשיגעון, אבל אין כזה. חלק ממה ש-sys_admin כתב פה זה דברים לא נכונים. חבל שזה מבלבל ומטעה אנשים.

[DanielGR]

לדעתי, יהיה נחמד אם תבדוק בעצמך ותעזור להשאיר את הסאגה הזו מאחור.

...

אני לא רוצה "קצוות פתוחים" אז הרמתי את הכפפה. יש לי את כל הציוד כדי לסמלץ את הסביבה במלואה:

* BPI-R4 - קנפיגורציית ברירת המחדל
* סוויץ' מנוהל CRS317, הגדרתי פורט מתויג של רשת ה- Guest שלי, כתובות 192.168.5.100-250 על ידי DHCP. פורט זה מחובר עם כבל DAC לפורט sfp-wan של BPI-R4
* ללא הגדרת vlan על bpi-r4 אין חיבור ולא מתקבלת כתובת - זו ההתנהגות המצופה

כעת לבדיקה על פי ההוראות של ג'מיני:

vlan על הפורט הפיזי

שיוך לממשק ה-wan

תוצאה: מתקבלת כתובת - תקין

משום מה הפורום לא מאפשר הוספה של יותר משלושה קבצים בהודעה, אפתח עוד הודעה.