switch controller design

H

hema

Guest
hii all,

I have a doubt regarding the design of switch controller on
fpga,first of all the switch has nothing to do with the ip addresses,it
works on mac addresses,but when u connect systems to a switch we
access using the ip adresses.through ARP it will know the mac
adresses.Now my doubt is when implementing the switch on a fpga how
will i make it supportive to ARP.please let me know the details,and
also for the first time how does the switching table is built?????

regards,
hema.
 
hema wrote:
hii all,

I have a doubt regarding the design of switch controller on
fpga,first of all the switch has nothing to do with the ip addresses,it
works on mac addresses,but when u connect systems to a switch we
access using the ip adresses.through ARP it will know the mac
adresses.Now my doubt is when implementing the switch on a fpga how
will i make it supportive to ARP.please let me know the details,and
also for the first time how does the switching table is built?????

regards,
hema.
Click to expand...
Assuming the switch is a layer II, it doesn't need to know anything but
the ethernet layer. ARP packets are sent to the ethernet broadcast
address (FF FF FF FF FF FF) when appropriate. The switch must
send all such packets to all ports. The devices plugged in need to deal
with ARP, not the switch itself.

The switch just looks at the source and destination MAC addresses.
If a packet comes in on port X from some source, the switch adds that
source to that port's list. So when a packet comes in with that MAC
addesss as a destination, it knows what port to send it to.

I think typical behavior if a switch doesn't know a port associated with
a destination MAC address is to just drop the packet. I suppose it could
also send it to all ports...

There is another issue, if there are loops in the way the ports are
wired up. Spanning tree protocol can be used to detect these. Most
cheap switches don't implement this.

-Dave


--
David Ashley http://www.xdr.com/dash
Embedded linux, device drivers, system architecture
 
David Ashley wrote:
hema wrote:

hii all,

I have a doubt regarding the design of switch controller on
fpga,first of all the switch has nothing to do with the ip addresses,it
works on mac addresses,but when u connect systems to a switch we
access using the ip adresses.through ARP it will know the mac
adresses.Now my doubt is when implementing the switch on a fpga how
will i make it supportive to ARP.please let me know the details,and
also for the first time how does the switching table is built?????

regards,
hema.



Assuming the switch is a layer II, it doesn't need to know anything but
the ethernet layer. ARP packets are sent to the ethernet broadcast
address (FF FF FF FF FF FF) when appropriate. The switch must
send all such packets to all ports. The devices plugged in need to deal
with ARP, not the switch itself.

The switch just looks at the source and destination MAC addresses.
If a packet comes in on port X from some source, the switch adds that
source to that port's list. So when a packet comes in with that MAC
addesss as a destination, it knows what port to send it to.

I think typical behavior if a switch doesn't know a port associated with
a destination MAC address is to just drop the packet. I suppose it could
also send it to all ports...

There is another issue, if there are loops in the way the ports are
wired up. Spanning tree protocol can be used to detect these. Most
cheap switches don't implement this.

-Dave
Click to expand...
Another point. Multicast traffic is another complication. Multicast is
identified by certain ranges of IP addresses. It may be that a multicast
packet has a destination MAC address of all FF's. I've seen the el cheapo
switches bog down with multicast traffic, they just send it to all ports.
Instead there is a protocol where receivers join a multicast channel,
and so switches only need forward multicast packets if any of the ports
have any receivers attached. Otherwise it can safely drop them.

I'm wondering what sort of switch one would make with an FPGA.
If you're targeting the low end market, forget it -- $5 for a 5 port switch
good luck trying to create an fpga solution in that range. High end
I can see a point, say a big 40 port switch where all the ports are
connected to a big fpga and it's a 1G or 10G switch...in that case
you need to have external memory for storing packets. No FPGA would
have enough BRAMs to handle the storage requirements necessary...

But if it's high end it'll probably need to be a layer III switch + know
about
IP + routing + multicast...in other words it gets to be a lot more
complicated.

-Dave


--
David Ashley http://www.xdr.com/dash
Embedded linux, device drivers, system architecture
 
hiiiii dave,

Thanks for your suggestion,give me some tips on how to
implement shared memory switch fabric and is a transceiver alone is
enough to make it work as a hub???
reply at the earliest.thank you.

regards,
hema.


David Ashley wrote:

David Ashley wrote:
hema wrote:

hii all,

I have a doubt regarding the design of switch controller on
fpga,first of all the switch has nothing to do with the ip addresses,it
works on mac addresses,but when u connect systems to a switch we
access using the ip adresses.through ARP it will know the mac
adresses.Now my doubt is when implementing the switch on a fpga how
will i make it supportive to ARP.please let me know the details,and
also for the first time how does the switching table is built?????

regards,
hema.



Assuming the switch is a layer II, it doesn't need to know anything but
the ethernet layer. ARP packets are sent to the ethernet broadcast
address (FF FF FF FF FF FF) when appropriate. The switch must
send all such packets to all ports. The devices plugged in need to deal
with ARP, not the switch itself.

The switch just looks at the source and destination MAC addresses.
If a packet comes in on port X from some source, the switch adds that
source to that port's list. So when a packet comes in with that MAC
addesss as a destination, it knows what port to send it to.

I think typical behavior if a switch doesn't know a port associated with
a destination MAC address is to just drop the packet. I suppose it could
also send it to all ports...

There is another issue, if there are loops in the way the ports are
wired up. Spanning tree protocol can be used to detect these. Most
cheap switches don't implement this.

-Dave



Another point. Multicast traffic is another complication. Multicast is
identified by certain ranges of IP addresses. It may be that a multicast
packet has a destination MAC address of all FF's. I've seen the el cheapo
switches bog down with multicast traffic, they just send it to all ports.
Instead there is a protocol where receivers join a multicast channel,
and so switches only need forward multicast packets if any of the ports
have any receivers attached. Otherwise it can safely drop them.

I'm wondering what sort of switch one would make with an FPGA.
If you're targeting the low end market, forget it -- $5 for a 5 port switch
good luck trying to create an fpga solution in that range. High end
I can see a point, say a big 40 port switch where all the ports are
connected to a big fpga and it's a 1G or 10G switch...in that case
you need to have external memory for storing packets. No FPGA would
have enough BRAMs to handle the storage requirements necessary...

But if it's high end it'll probably need to be a layer III switch + know
about
IP + routing + multicast...in other words it gets to be a lot more
complicated.

-Dave


--
David Ashley http://www.xdr.com/dash
Embedded linux, device drivers, system architecture
Click to expand...
 
hema wrote:
hiiiii dave,

Thanks for your suggestion,give me some tips on how to
implement shared memory switch fabric and is a transceiver alone is
enough to make it work as a hub???
reply at the earliest.thank you.

regards,
hema.
Click to expand...
Regarding a hub, I think all ports on the hub are wired
together in some way, since collisions can occur. But I
don't know details. Regarding your other question, I have
no idea how to answer. Usually one conceives of an
overall architecture for a solution, then breaks it up
into pieces, then tackles each one until the job is done.
I don't think you can count on a newsgroup for doing your
entire job for you :). General tips + theory are possible.

-Dave

--
David Ashley http://www.xdr.com/dash
Embedded linux, device drivers, system architecture
 
David Ashley <dash@nowhere.net.dont.email.me> writes:

hema wrote:

Thanks for your suggestion,give me some tips on how to
implement shared memory switch fabric and is a transceiver alone is
enough to make it work as a hub???
reply at the earliest.thank you.

Regarding a hub, I think all ports on the hub are wired
together in some way, since collisions can occur.
Click to expand...
As far as I know, correct. In Ethernet, all the PHY's in a hub are
logically connected to a shared bus, and traffic on more than one port
results in a collision on the bus and hence on the ports.

As for shared-memory switch fabric design, I suggest you (ie: hema)
look up some books on the subject, go hunting on the websites of
companies such as broadcom, marvell, and vitesse, look in the patent
litterature, and in conference proceedings. That should provide you
with plenty of leads.


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>
 
"hema" <ashu_19_1980@yahoo.com> writes:

hii all,

I have a doubt regarding the design of switch controller on
fpga,first of all the switch has nothing to do with the ip addresses,it
works on mac addresses,but when u connect systems to a switch we
access using the ip adresses.through ARP it will know the mac
adresses.Now my doubt is when implementing the switch on a fpga how
will i make it supportive to ARP.please let me know the details,and
also for the first time how does the switching table is built?????
Click to expand...
Normally, a L2 switch won't listen/participate in ARP (only advanced
switch/routers do this). ARP translates from L3 (IP) addresses to L2
(MAC) addresses.

If all you want is to learn where your L2 addresses are, the standard
solution is "backward learning". Google is your friend:
http://www.google.com/search?hl=en&q=backward+learning

Regards,


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>
 
hiiii,

In case of designing the switch controller on FPGA ,how to resolve the
contention when all the input buffers(FIFO) try out for the same output
FIFO????

regards,
hema.
Kai Harrekilde-Petersen wrote:
"hema" <ashu_19_1980@yahoo.com> writes:

hii all,

I have a doubt regarding the design of switch controller on
fpga,first of all the switch has nothing to do with the ip addresses,it
works on mac addresses,but when u connect systems to a switch we
access using the ip adresses.through ARP it will know the mac
adresses.Now my doubt is when implementing the switch on a fpga how
will i make it supportive to ARP.please let me know the details,and
also for the first time how does the switching table is built?????

Normally, a L2 switch won't listen/participate in ARP (only advanced
switch/routers do this). ARP translates from L3 (IP) addresses to L2
(MAC) addresses.

If all you want is to learn where your L2 addresses are, the standard
solution is "backward learning". Google is your friend:
http://www.google.com/search?hl=en&q=backward+learning

Regards,


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk
Click to expand...
 
hema wrote:

In case of designing the switch controller on FPGA ,how to resolve the
contention when all the input buffers(FIFO) try out for the same output
FIFO????
Click to expand...
Choose a winner and lock out the others.

-- Mike Treseler
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top