Reply by robe...@yahoo.com●March 31, 20082008-03-31
On Mar 29, 5:39 am, David Brown
<david.br...@hesbynett.removethisbit.no> wrote:
> As for bridging protocols between the "LAN" ports and "WAN" port on a
> typical DSL router, the reason you can't do it is that very few people
> would want to do that. I can't think of any non-IP or broadcast traffic
> that you would want to share between the LAN and WAN on a normal setup.
Well the definitions mostly were generic, and not specific to the
"typical" DSL router. The typical DSL router does only IP out the WAN
side, not least because that's all the ISP at the other end supports.
OTOH, bridges in general (and non-IP routers) are often used to move
non-IP traffic across WANs. There's certainly less of that then there
used to be, especially in proportionate terms, but some of use still
run things like straight SNA over our WAN links (although you can
tunnel SNA over IP these days), often in parallel with routable
protocols like IP.
Reply by Eric Smith●March 29, 20082008-03-29
Keith M wrote:
> Cisco's executable images are up to 20mb a pop, and that firmware is
> stored in the flash. I forget whether 20mb is compressed or not
On at least some models, the images are compressed, and in compressed
form occupy more than 20MB.
Reply by David Brown●March 29, 20082008-03-29
robertwessel2@yahoo.com wrote:
> On Mar 28, 12:57 pm, David Brown
> <david.br...@hesbynett.removethisbit.no> wrote:
>> I think it is pretty important to establish exactly what is meant by
>> "router", "bridge", and "switch", since I am not sure we have the same
>> definitions (or else I am misunderstanding what you wrote). So correct
>> me if you think I've got something wrong here.
>>
>> A "bridge" is a device that has two or more network ports, and which
>> passes traffic between the ports (which may be of different types -
>> e.g., WLAN, 100 MBit and 1 Gb ports). It is a Layer 2 (e.g., Ethernet)
>> device, and has no concept of IP addresses. A bridge will typically
>> automatically learn which Ethernet MAC addresses are attached to its
>> ports, so that traffic is only passed to ports that have the destination
>> MAC address attached (broadcasts are passed to all ports). Normally, no
>> filtering or interpretation of the packets is done.
>>
>> A "switch" is a type of bridge that is specialised for low-latency
>> bridging of Ethernet packets, allowing packets to pass through different
>> pairs of ports simultaneously. It is also possible to have purely
>> software bridges (such as bridges in Linux, which can also have
>> filtering tables).
>>
>> A "router" has two or more network ports and passes packets between them
>> based on their IP addresses (Layer 3), or possibly other higher layers.
>> The router may also have virtual network ports for vpns, it may also
>> modify the packets (such as for NAT or some kinds of vpn), and it may
>> have filters (a firewall) for the packets.
>>
>> A "layer 3 switch" is a sort of combined layer 2 switch and layer 3
>> router, normally with specialised hardware to do the routing as fast as
>> possible.
>>
>> Given that the OP wants to support BGP, which is used to track layer 3
>> IP routes, I expect that it is a layer 3 router that he wants to make.
>> Whether it is between different LANs, or between LAN(s) and WAN(s), I
>> don't know - presumably it's for a complex setup, since a common tree
>> hierarchy does not need BGP as there are never alternative routes.
>>
>> The typical DSL router device is actually a combination of a bridge, a
>> switch, and a router (and is therefore a "router"). You normally get
>> four LAN ports which are connected together by a switch, a WLAN
>> interface which is bridged to the switch, and a router (with NAT and a
>> firewall) connecting the LAN switch to the WAN port.
>
>
> There is no difference between a switch and a bridge. The former is
> the more fashionable marketing term. Some early switches where
> characterised by having cut-through forwarding, but that's almost
> impossible to do with mixed link speeds, and the reduced latency at
> the faster speeds makes it a non-issue anyway.
>
> A layer-3 switch is a router. Again, routers are (or were) pass�, and
> switches were fashionable, hence the brand extension for the marketing
> term switch. "Layer-3 router" is redundant and repetitive.
>
> Devices that route some protocols and bridge other were once called
> brouters, but I haven't heard the term in years, and bridging is an
> optional function of most medium and high end routers.
>
> NAT and VPN functions are common on non-low-end routers, although they
> don't necessarily require much in the way of routing function.
>
> The typical DSL router is really several devices in one box, and is
> both a bridge and a router in the sense described above. As you
> described, it's really a switch connecting the Ethernet ports, router
> (when then heads out to DSL port) and access point. That differs from
> the prior scenario in that it cannot bridge a protocol out the DSL
> port (which a proper bridge/router could).
That sounds like we agree on the terms.
As for bridging protocols between the "LAN" ports and "WAN" port on a
typical DSL router, the reason you can't do it is that very few people
would want to do that. I can't think of any non-IP or broadcast traffic
that you would want to share between the LAN and WAN on a normal setup.
Once you get to the size of network where there are multiple possible
routes between the LAN and external networks, you might want to make use
of ICMP packets and BGP in a more flexible way, but even then it's more
likely that you'll want to set up specific routes (http over ADSL, email
over an SHDSL line, for example). People configuring more advanced
networks with multiple WAN lines, multiple globally addressable servers,
etc., do not normally by their network equipment off the shelf at their
local PC World.
However, it's mostly just a matter of software - I regularly use openwrt
on LinkSys WRT54GL wireless routers. The hardware is cheap and
reliable, and by replacing the firmware with openwrt, I get all the
flexibility I could need. Typically I want to set up more restrictions
(such as separate independent LANs) rather than allowing more traffic
through, but pretty much any networking setup is possible once you have
low-level access to a Linux setup.
Reply by dspfun●March 29, 20082008-03-29
On 28 Mar, 16:41, Keith M <keit...@yanktheobvious.verizon.net> wrote:
> dspfun wrote:
>
> (after snipping)
>
> > So, how many MPPS (64-byte packets) can a FPGA forward?
>
> > What would you estimate the highest possible packet forwarding rate
> > (MPPS) to for a single high-end FPGA?
>
> I really don't think anyone could possibly answer these questions. =A0It's=
> worse than asking how fast a race car could go if you use a really big
> engine. =A0There are just too many variables:
>
> size
> weight of the car
> aerodynamics of the car
> type of fuel
> type of tires
> transmission
>
I guess a more sharp question could be, what is the fastest rate an
FPGA can forward packets if:
1) No accesses to external memory is required (complete packets run
through the FPGA).
2) One access to the fastest off-the-shelf SRAM memories is required.
Two, three, four accesses?
3) One access to the fastest off-the-shelf SDRAM memories is
required. Two, three, four accesses?
I guess the number of accesses to external memories and the access/
throughput speeds of the memories are the main thing that limits
packet forwarding rate an FPGA.
For the racecar analogy, a gut feeling could be that a racecar can be
built running faster than 300 km/h, but probably not faster than 600
km/h, a likely speed might be around 400-500 km/h if it is to race
agains other cars on a curved track.
Reply by robe...@yahoo.com●March 28, 20082008-03-28
On Mar 28, 12:57 pm, David Brown
<david.br...@hesbynett.removethisbit.no> wrote:
> I think it is pretty important to establish exactly what is meant by
> "router", "bridge", and "switch", since I am not sure we have the same
> definitions (or else I am misunderstanding what you wrote). So correct
> me if you think I've got something wrong here.
>
> A "bridge" is a device that has two or more network ports, and which
> passes traffic between the ports (which may be of different types -
> e.g., WLAN, 100 MBit and 1 Gb ports). It is a Layer 2 (e.g., Ethernet)
> device, and has no concept of IP addresses. A bridge will typically
> automatically learn which Ethernet MAC addresses are attached to its
> ports, so that traffic is only passed to ports that have the destination
> MAC address attached (broadcasts are passed to all ports). Normally, no
> filtering or interpretation of the packets is done.
>
> A "switch" is a type of bridge that is specialised for low-latency
> bridging of Ethernet packets, allowing packets to pass through different
> pairs of ports simultaneously. It is also possible to have purely
> software bridges (such as bridges in Linux, which can also have
> filtering tables).
>
> A "router" has two or more network ports and passes packets between them
> based on their IP addresses (Layer 3), or possibly other higher layers.
> The router may also have virtual network ports for vpns, it may also
> modify the packets (such as for NAT or some kinds of vpn), and it may
> have filters (a firewall) for the packets.
>
> A "layer 3 switch" is a sort of combined layer 2 switch and layer 3
> router, normally with specialised hardware to do the routing as fast as
> possible.
>
> Given that the OP wants to support BGP, which is used to track layer 3
> IP routes, I expect that it is a layer 3 router that he wants to make.
> Whether it is between different LANs, or between LAN(s) and WAN(s), I
> don't know - presumably it's for a complex setup, since a common tree
> hierarchy does not need BGP as there are never alternative routes.
>
> The typical DSL router device is actually a combination of a bridge, a
> switch, and a router (and is therefore a "router"). You normally get
> four LAN ports which are connected together by a switch, a WLAN
> interface which is bridged to the switch, and a router (with NAT and a
> firewall) connecting the LAN switch to the WAN port.
There is no difference between a switch and a bridge. The former is
the more fashionable marketing term. Some early switches where
characterised by having cut-through forwarding, but that's almost
impossible to do with mixed link speeds, and the reduced latency at
the faster speeds makes it a non-issue anyway.
A layer-3 switch is a router. Again, routers are (or were) pass=E9, and
switches were fashionable, hence the brand extension for the marketing
term switch. "Layer-3 router" is redundant and repetitive.
Devices that route some protocols and bridge other were once called
brouters, but I haven't heard the term in years, and bridging is an
optional function of most medium and high end routers.
NAT and VPN functions are common on non-low-end routers, although they
don't necessarily require much in the way of routing function.
The typical DSL router is really several devices in one box, and is
both a bridge and a router in the sense described above. As you
described, it's really a switch connecting the Ethernet ports, router
(when then heads out to DSL port) and access point. That differs from
the prior scenario in that it cannot bridge a protocol out the DSL
port (which a proper bridge/router could).
Reply by David Brown●March 28, 20082008-03-28
Keith M wrote:
> David Brown wrote:
>
>> As far as I can tell, he is thinking of a routing packets as fast as
>> possible between networks, not handling the packets on the system
>> itself (except as needed for routing protocols).
>
> Between networks? You mean between local LANs? Or between a LAN and WAN?
> 99%+ of the routers out there bridge(ahem, route) LAN to WAN. I know
> these terms start getting diluted when we start cable and DSL, so let's
> not. :)
>
> There's a big difference between Layer 3 support on a switch (that
> happens to support BGP) and a router.
>
I think it is pretty important to establish exactly what is meant by
"router", "bridge", and "switch", since I am not sure we have the same
definitions (or else I am misunderstanding what you wrote). So correct
me if you think I've got something wrong here.
A "bridge" is a device that has two or more network ports, and which
passes traffic between the ports (which may be of different types -
e.g., WLAN, 100 MBit and 1 Gb ports). It is a Layer 2 (e.g., Ethernet)
device, and has no concept of IP addresses. A bridge will typically
automatically learn which Ethernet MAC addresses are attached to its
ports, so that traffic is only passed to ports that have the destination
MAC address attached (broadcasts are passed to all ports). Normally, no
filtering or interpretation of the packets is done.
A "switch" is a type of bridge that is specialised for low-latency
bridging of Ethernet packets, allowing packets to pass through different
pairs of ports simultaneously. It is also possible to have purely
software bridges (such as bridges in Linux, which can also have
filtering tables).
A "router" has two or more network ports and passes packets between them
based on their IP addresses (Layer 3), or possibly other higher layers.
The router may also have virtual network ports for vpns, it may also
modify the packets (such as for NAT or some kinds of vpn), and it may
have filters (a firewall) for the packets.
A "layer 3 switch" is a sort of combined layer 2 switch and layer 3
router, normally with specialised hardware to do the routing as fast as
possible.
Given that the OP wants to support BGP, which is used to track layer 3
IP routes, I expect that it is a layer 3 router that he wants to make.
Whether it is between different LANs, or between LAN(s) and WAN(s), I
don't know - presumably it's for a complex setup, since a common tree
hierarchy does not need BGP as there are never alternative routes.
The typical DSL router device is actually a combination of a bridge, a
switch, and a router (and is therefore a "router"). You normally get
four LAN ports which are connected together by a switch, a WLAN
interface which is bridged to the switch, and a router (with NAT and a
firewall) connecting the LAN switch to the WAN port.
mvh.,
David
Reply by Keith M●March 28, 20082008-03-28
David Brown wrote:
> As far as I can tell, he is thinking of a routing packets
> as fast as possible between networks, not handling the packets on the
> system itself (except as needed for routing protocols).
Between networks? You mean between local LANs? Or between a LAN and WAN?
99%+ of the routers out there bridge(ahem, route) LAN to WAN. I know
these terms start getting diluted when we start cable and DSL, so let's
not. :)
There's a big difference between Layer 3 support on a switch (that
happens to support BGP) and a router.
> The Cisco box
> is for connecting together LANs, telephones, WLANs, WANs and VPNs, and
> thus needs vastly more software support.
I can't speak for the OP, but if he needs BGP support, then he's
probably doing LAN to WAN. MAYBE WAN to WAN. But who has single gig or
10gig WAN links anyways? Besides Internet2?
And the Cisco I picked is smack-dab in the middle of their product line,
at least for supporting T3 links. Which I picked out of the air. T3 is
pretty fast and my contention was that was larger/bigger/faster router
is likely to have additional hardware required to support it.
> 20 MB compressed firmware
> still sounds a bit bloated (I have routers supporting LANs, WLANs, VPNs,
> WANs, NAT, firewalls, and many other TLAs, running from about 2.5 MB
> compressed firmware), but nearly as much in view of all the other stuff
> it supports.
Yeah, I don't think there's any doubt that it's bloated. My real point
was that 64mb flash is actually REQUIRED, at least on the Cisco
platform, for many of their IOS's. There are several other router
vendors who have similar memory requirements, Nortel Networks comes to
mind as well.
I fully appreciate the fact that there's a difference between what Cisco
and Nortel REQUIRE, and what the APPLICATION might require.
Keith
Reply by Keith M●March 28, 20082008-03-28
dspfun wrote:
(after snipping)
> So, how many MPPS (64-byte packets) can a FPGA forward?
>
> What would you estimate the highest possible packet forwarding rate
> (MPPS) to for a single high-end FPGA?
I really don't think anyone could possibly answer these questions. It's
worse than asking how fast a race car could go if you use a really big
engine. There are just too many variables:
size
weight of the car
aerodynamics of the car
type of fuel
type of tires
transmission
The same idea with routers. It all depends on the architecture of the
router. And what design tradeoffs you make when putting it all
together. Don't underestimate the effect any type of filtering would
have on the flow. Any type of access-lists, with most of the Cisco
designs, require that the CPU handle each and every packet and inspect
the rule-list (which can be large, depending on the application) for a
matching rule. Don't even get me started on firewall packet inspection,
it's much worse. And then you have NAT lookups, and routing decisions
to make on potentially HUGE BGP routing tables.
And even after you've decided on how you are going to approach designing
the thing, you've got to look at how efficient you are in coding the
design. Maybe the particular approach is no good, or maybe the
execution of the design just sucks. There are a million factors that
affect router performance.
And then you make things harder by going above a 100mbps connection.
Many routers don't need gig ports on them (let alone 10gig) because they
simply can't handle the traffic. There's been a recent push the last
couple years where routers are starting to have gig ports, but it's just
because the standard chipsets are supporting 10/100/1000 --- not because
they provide any performance improvement.
I've talked with customers who demand a gigabit port on their router,
only to find out their WAN connection is a T1 or cable or dsl.
ymmv and hth.
Keith
Reply by David Brown●March 28, 20082008-03-28
Keith M wrote:
> David Brown wrote:
>
>> I certainly can't imagine what you'd want with 64 MB flash - even if
>> you run a non-specialised kernel such as Linux on your router, the
>> kernel, all the networking, routing and filtering code, and the basic
>> configuration tools will fit in about 2 MB. Add another 2 MB for a
>> fancy web interface if you want.
>
> Cisco's executable images are up to 20mb a pop, and that firmware is
> stored in the flash. I forget whether 20mb is compressed or not -- it
> might be. Cisco is the big dog with lotsa features, so they might be an
> extreme case.
>
> I tried like heck this morning to find the memory timeline/roadmap on
> Cisco's site, but no can do. However the Cisco 3845 datasheet
>
> http://www.cisco.com/en/US/prod/collateral/routers/ps5855/product_data_sheet0900aecd8016a8e8.html
>
>
> and see under memory
>
> � Default-64 MB Compact Flash; 256 MB DDR SDRAM
>
> I honestly don't know what the breakdown of why that much is required
> --- but can tell you from practical experience that 64/256mb is
> considered standard for low-midrange (Note I'm specifically excluding
> SOHO routers) full-featured routers. The Cisco 3845 maxes out around T3
> speeds. The larger routers have larger requirements --- but note that
> memory doesn't scale with bandwidth........ you don't necessarily need
> more memory to support higher throughput.
>
> However, I can tell you that having support for many different types of
> modules, many different WAN protocols, VPN support, firewall support,
> VOIP support, etc etc etc Executable image size and memory requirements
> can skyrocket. Memory requirements are going to hinge exactly on what
> features you intend on supporting.
>
> Keith
I had a little look at the link you gave - the Cisco box shown there
does not look remotely like the sort of device I imagine the OP is
thinking of. As far as I can tell, he is thinking of a routing packets
as fast as possible between networks, not handling the packets on the
system itself (except as needed for routing protocols). The Cisco box
is for connecting together LANs, telephones, WLANs, WANs and VPNs, and
thus needs vastly more software support. 20 MB compressed firmware
still sounds a bit bloated (I have routers supporting LANs, WLANs, VPNs,
WANs, NAT, firewalls, and many other TLAs, running from about 2.5 MB
compressed firmware), but nearly as much in view of all the other stuff
it supports.
Reply by Didi●March 28, 20082008-03-28
dspfun wrote:
> ...
> The design I had in mind would be a system on a chip plus high-end
> external memories. It would look something like this:
>
> In the SOC (i.e. the FPGA):
> Two PPC440 CPUs handling BGP and OSPF (i.e. control plane). The fast
> path/data plane is all handled in the FPGA-code, i.e. packet
> forwarding/routing.
> ...
You may want to investigate the products Freescale have on offer.
You sound like you are trying to reinvent some of their PPC based
QUICK and sort of parts.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
dspfun wrote:
> On Mar 28, 9:19 am, David Brown <da...@westcontrol.removethisbit.com>
> wrote:
> > Keith M wrote:
> > > aubrey wrote:
> >
> > >> I discovered that the MIPS architecture is widely licensed and used
> > >> frequently in common embedded applications. For example, the DI-525
> > >> router, hardware version C, uses a System on a Chip with the MIPS
> > >> instruction set, FLASH, and RAM. Lots of flash and ram, like 16Mb RAM
> > >> and 4Mb Flash (various posts cite different numbers).
> >
> > > I've often thought about buying some of these devices just to have a
> > > working platform. If you buy all that stuff separately, it would cost
> > > you a fortune. Those people hacking those devices are pretty crazy in
> > > their reverse engineering skills.
> >
> > > Yeah 16mb of ram and 4mb of flash is a lot of memory. However, if you
> > > compare it to today's serious routers(anything even remotely close to
> > > the OP's idea), it's not nearly enough. I just recently fitted a Cisco
> > > with 64MB flash and 256MB DRAM. It doesn't have the most complete
> > > feature set either...... and if you look at Cisco's memory roadmap, it
> > > will probably need upgraded by 2009. And this was in a router designed
> > > to handle T3 speeds. 45mbps.
> >
> > I can see how you might have use for more RAM - storing bigger routing
> > tables, ARP caches, connection trackings, and so on, as well as doing
> > some packet buffering. But I have difficulty seeing how you would fill
> > 256 MB with this sort of thing unless you are switching a lot of 10 GB
> > lines with serious congestions - your aim in the router is to pass
> > packets through without storing them, unless it is absolutely necessary
> > (such as because of differences in line speeds). I certainly can't
> > imagine what you'd want with 64 MB flash - even if you run a
> > non-specialised kernel such as Linux on your router, the kernel, all the
> > networking, routing and filtering code, and the basic configuration
> > tools will fit in about 2 MB. Add another 2 MB for a fancy web
> > interface if you want.
>
> Thank you all for your input!
>
> The design I had in mind would be a system on a chip plus high-end
> external memories. It would look something like this:
>
> In the SOC (i.e. the FPGA):
> Two PPC440 CPUs handling BGP and OSPF (i.e. control plane). The fast
> path/data plane is all handled in the FPGA-code, i.e. packet
> forwarding/routing.
>
> The external memories would consist of something like 64 MB Flash, 128
> MB QDRII+ SRAM and 1 GB of DDR3 SDRAM (maybe need to adjust some of
> the sizes).
>
> A 1 Gbps interface means forwarding 64-byte packets at a rate of 2
> MPPS. Four 1 Gbps interface -> 4x2 MPPS = 8 MPPS packet forwarding.
>
> A 10 Gbps interface means forwarding 64-byte packets at a rate of 20
> MPPS. Four 10 Gbps interface -> 4x20 MPPS = 80 MPPS packet forwarding.
>
> So, how many MPPS (64-byte packets) can a FPGA forward?
>
> As far as I have understood a high-end FPGA with fast external
> memories should be able to forward packets at a rate of 20 MPPS.
>
> Having four 10 Gbps interfaces means that the FPGA would have to
> forward packets at a rate of 4x20 MPPS= 80 MPPS, is that not possible?
>
> What would you estimate the highest possible packet forwarding rate
> (MPPS) to for a single high-end FPGA?