স্যুইচগুলি ম্যাক-ঠিকানাগুলি পুনরায় লেখবে না কেন?


10

ইথারনেট স্যুইচগুলি কোনও প্যাকেটের ম্যাক ঠিকানা পরিবর্তন না করার কোনও কারণ আছে কি?

এটি ম্যাক ঠিকানা, বা অন্য কিছু ব্যবহার করে শেষ হোস্ট সনাক্তকরণের জন্য?


5
মনে করুন আপনার নাম কুমার ছিল। লোকেরা যদি আপনাকে "জেসিকা" বলতে শুরু করে তবে আপনি কি এটি পছন্দ করতে পারেন?
মাইক পেনিংটন

1
স্যুইচগুলি প্যাকেটগুলি (ফ্রেম) পুনর্লিখন করে না; এগুলি কেবল ইন্টারফেস থেকে ইন্টারফেসে নিয়ে যায়। (সম্প্রচার / মাল্টিকাস্টের ক্ষেত্রে এটি একাধিক বন্দরে অনুলিপি সহ অন্তর্ভুক্ত))
রিকি বিম

4
আপনি কী কোনও বৈধ কারণ সম্পর্কে ভাবতে পারেন যে স্যুইচের ম্যাক ঠিকানা পরিবর্তন করা উচিত ?
টিউন ভিঙ্ক

কোন উত্তর কি আপনাকে সাহায্য করেছে? যদি তা হয় তবে আপনার উত্তরটি গ্রহণ করা উচিত যাতে উত্তরটি সন্ধান চিরকালের জন্য পপিং না হয়ে থাকে। বিকল্পভাবে, আপনি নিজের উত্তর সরবরাহ করতে এবং গ্রহণ করতে পারেন।
রন মউপিন

উত্তর:


10

যদি একটি স্যুইচ ম্যাক ঠিকানা পরিবর্তন করতে থাকে তবে এটি নেটওয়ার্কিং পুরোপুরি ভেঙে দেবে।

ম্যাক ঠিকানাটি একটি অনন্য শনাক্তকারী যা স্থানীয় নেটওয়ার্কে হোস্টগুলি ব্যবহার করে।

যদি স্যুইচটি গন্তব্য ম্যাকটি পরিবর্তন করতে থাকে তবে ফ্রেমটি উপযুক্ত হোস্টের কাছে পৌঁছে দেওয়া হবে না। এটির ক্ষেত্রে, উদাহরণস্বরূপ যদি ফ্রেম প্লাবিত হয় তবে গন্তব্য হোস্টটি এটি ফেলে দেবে কারণ এটি আর হোস্টের জন্য নির্ধারিত হবে না।

যদি স্যুইচটি উত্স ম্যাকের ঠিকানাটি পরিবর্তন করতে থাকে তবে গন্তব্য হোস্টটি কোনও প্রতিক্রিয়া (খারাপ ডেটার সাথে কোনও এআরপি এন্ট্রি আপডেট করা সহ) এই ম্যাক ঠিকানাটি ব্যবহার করবে। এর ফলে আমি আগেই বর্ণিত একই পরিস্থিতি তৈরি করব, কেবল সমস্ত ফিরতি ট্র্যাফিকের জন্য।

এটি 802.1X এবং অন্যান্য মেকানিজমগুলির মতো জিনিসগুলির সাথে আরও সমস্যা তৈরি করতে পারে যা ম্যাক ঠিকানা ব্যবহার করে ডিভাইসটি সনাক্ত / শ্রেণিবদ্ধ করার জন্য।

এটি করার জন্য কী কী পদ্ধতি তৈরি করা যেতে পারে? আমি নিশ্চিত তারা পারে। তবে এই মুহুর্তে এটি করার কোনও কারণ নেই এবং এটি কেবল নেটওয়ার্কিংকে জটিল করে তুলবে এবং অপ্রয়োজনীয় প্রক্রিয়াজাতকরণ যুক্ত করবে। আমরা উপলভ্য ম্যাক অ্যাড্রেস পুলটি ক্লান্ত করার কাছাকাছি নেই তাই ম্যাটের মতো কোনও কিছুর প্রয়োজন নেই (ম্যাকের ঠিকানা অনুবাদের ধারণাটি কোথাও উপস্থিত রয়েছে কিনা তা জানেন না তাই আমি কেবল একটি শব্দ তৈরি করেছি?)।


4

ডাটাগ্রামের ঠিকানাগুলির পুনরায় লেখাগুলি স্তর 3 এ ঘটে উদাহরণস্বরূপ যখন গেটওয়েগুলি (রাউটার বা ফায়ারওয়াল) চলমান NAT অভ্যন্তরীণ নেটওয়ার্কে হোস্টগুলির আইপি ঠিকানাগুলি পুনরায় লেখায় যাতে সেগুলি সমস্ত গেটওয়েতেই একটি (বা কয়েকটি) বহিরাগত আইপি ঠিকানা থেকে উপস্থিত হয়।

লেয়ার 2 স্তরে অনুরূপ কিছু না হওয়ার কারণ (যেখানে আমরা হোস্টগুলি আলাদা করতে ম্যাকের ঠিকানাগুলি ব্যবহার করি এবং সুইচগুলি ডেটাগ্রামের চলাচল করে, এটি ফ্রেম হয়) উপরের মন্তব্যে বলা হয়েছে যে এর সত্যিকার প্রয়োজন নেই।

NAT এর সাথে লেয়ার থ্রি ক্ষেত্রে ন্যাট সমস্যা সমাধান করে:

  • আইপি ঠিকানাগুলি বিশ্বব্যাপী যোগাযোগের জন্য ব্যবহৃত হয় এবং আইপি ঠিকানার একটি সীমিত পুল পাওয়া যায় যা ভাগ করে নিতে হয়। NAT ব্যবহার করে, কেউ নিশ্চিত করে যে বৃহত সংখ্যক অভ্যন্তরীণ হোস্ট জনসাধারণের ইন্টারনেটে দৃশ্যমান আইপি ঠিকানা কম (সাধারণত একটি মাত্র) IP ভাগ করতে পারে।
  • আইপি ঠিকানার পুনর্লিখনকে কেউ কেউ বিবেচনা করে তবে অভ্যন্তরীণ মেশিনগুলির আইপি অ্যাড্রেসগুলি ছড়িয়ে দিয়ে সুরক্ষার একটি স্তর যুক্ত করার জন্য সবাই নয় not

সুতরাং, আমরা যদি NAT উদাহরণের সাথে লেগে থাকি, তবে সত্যই NAT এর একটি স্তর দুই অংশের দরকার নেই।

  • ইন্টারনেটে ডেটাগ্রামে সম্বোধনের জন্য ম্যাক ঠিকানা বিশ্বব্যাপী ব্যবহার করা হয় না, সেগুলি স্থানীয় সাবনেটের ডান হোস্টগুলিতে ফ্রেম প্রেরণের জন্য ব্যবহৃত হয়। যেহেতু স্থানীয় সাবনেটগুলি তুলনামূলকভাবে ছোট, এবং সম্ভাব্য ম্যাকের ঠিকানাগুলির সংখ্যা খুব বড়, স্তর স্তর 2 স্তরে উপলব্ধ ম্যাক ঠিকানাগুলি "আউট" হয় না। (এনআইসিসের ম্যাকের ঠিকানাগুলিকে একটি স্বেচ্ছাসেবী মানতে ম্যানুয়ালি কনফিগার করার বিকল্পটি এটি পরিবর্তন করে না)
  • এবং ফরোয়ার্ড করার সময় ডেটাগ্রাম ঠিকানার পুনর্লিখনের বিতর্কযোগ্য সুরক্ষার সুবিধার জন্য: কেবলমাত্র স্থানীয় সাবনেটের মধ্যে যেমন MAC ঠিকানা ব্যবহার করা হয়, তখন সাধারণত একটি আপেক্ষিক ভাষায়, সেই সাবনেটের উপর সুরক্ষা দৃষ্টিকোণ থেকে অনেক ভাল নিয়ন্ত্রণ (শারীরিকভাবে এবং বেশিরভাগ ক্ষেত্রে) জড়িত ডিভাইসগুলি) লেয়ার 3 কেস-এর সাথে তুলনা করা, যা সম্পূর্ণ ইন্টারনেট (যা আমরা ব্যবহারকারীর সাথে সংযুক্ত ব্যবহারকারী এবং নেটওয়ার্ক ইঞ্জিনিয়ারদের বাস্তবে কোনও সুরক্ষা নিয়ন্ত্রণ নেই)।

আশা করি এটি কেন সুইচগুলি ম্যাক ঠিকানাগুলি পুনরায় লেখেন না over আমার মাথার উপরে থেকে একমাত্র স্তর 3 কেসটি নিয়ে এসেছিল NAT, অন্যরা অবশ্যই অন্যান্য স্তর 3 এর উদাহরণ প্রদান করতে পারে যেখানে আইপি পুনর্লিখনগুলি নিশ্চিত করা হয় (এবং কেন সেই প্রযুক্তিগুলি স্তর 2 স্তরের সত্যিকার অর্থে বোঝায় না) ।


3
স্পট-অন, তবে আপনার উত্তরটির সাথে আমার একটি ছোট্ট ছোট্ট বাচ্চা আছে। আপনি উল্লেখ করেছেন যে "NAT এর দুই স্তরের অংশের প্রকৃত পক্ষে দরকার নেই" ... আমি যখন ম্যাক NAT দেখিনি, আমি ম্যাক-লেভেল টানেলিংটি দেখেছি। কিছু পরিস্থিতিতে, অন্য ম্যাক-অ্যাড্রেসের ভিতরে "টানেল" ম্যাক ঠিকানাগুলিতে স্যুইচ করার পক্ষে এটি অর্থবোধ করে। অবিলম্বে যে পরিস্থিতি মাথায় আসে সেটি হ'ল আইইইই 802.1ah সরবরাহকারী ভিত্তিক ব্রিজিং (পিবিবি) । সাধারণত, এটি পরিষেবা সরবরাহকারী মেট্রোর রিংগুলিতে উপলব্ধ ভ্লানগুলি / ম্যাক শেখার পরিমাণ কমিয়ে দেওয়ার জন্য ব্যবহৃত হয়
মাইক পেনিংটন

1
@ ইলভিলজা: ভাল বলেছেন ..! আপনি একটি সন্দেহ সমাধান করেছেন যা আমাকে কয়েক সপ্তাহ ধরে বিভ্রান্ত করেছে। কয়েক সপ্তাহ আগে, আমি নিম্নলিখিত হিসাবে ভেবেছিলাম ... "একটি রাউটার যখন এটি ডাব্লুএইএন-এর সাথে লেনদেন করে তখন প্রেরকের ম্যাক ঠিকানার পরিবর্তে (প্রতিটি প্যাকেটে) ম্যাকের ঠিকানা রাখে এবং প্যাকেটগুলি রিসিভারে দেয়। তবে ক্ষেত্রে ল্যান, রাউটারটি প্রেরকের ম্যাক ঠিকানার পরিবর্তে (প্রতিটি প্যাকেটে) তার ম্যাক ঠিকানা রাখে না তবে কেবল প্রেরক এবং গ্রহণকারীর মধ্যে প্যাকেটগুলি পাস করে "তবে আপনার ব্যাখ্যা পরে আমি 'রাউটার' এবং 'এর মধ্যে পার্থক্য করার পক্ষে যথেষ্ট পরিষ্কার করেছি একটি সুইচ'. আবার ধন্যবাদ..!
মহারান

0

ম্যাক ঠিকানার পুনর্লিখনে যথেষ্ট জটিলতা যুক্ত হবে (সুইচটি আরপের মতো উচ্চ স্তরের প্রোটোকলগুলি সম্পর্কে জানতে হবে যাতে এটি ঠিকানার পুনর্লিখনটি আবারও লিখতে পারে), সমস্যা সমাধানের কাজটি আরও শক্ত করে তোলে, এসটিপির মতো প্রোটোকলকে কাজ করা থেকে বিরত রাখত এবং সাধারণত পিআইটিএ হতে পারে। এটি সাধারণত প্রয়োজন হয় না।

যা বলা সম্ভব নয় এটি সম্ভব নয়। ইবেটবেবলস (আইপেটেবলের কাছে স্তর 2 স্তর) ম্যাক ঠিকানা অনুবাদের জন্য কিছু বিকল্প রয়েছে। আপনার যদি সুইচগুলি প্রতি ভ্যালান ম্যাক টেবিল ব্যবহার না করে এবং আপনি কিছু স্তর 2 ফিল্টারিং করতে চান তবে এটি কার্যকর হতে পারে।

http://ebtables.netfilter.org/examples/example1.html

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.