I never thought of it as an efficiency, more a deficiency in that it's missing something. It makes sense though that it has to be processed either way. So if I'm understanding correctly, the only real issue I cold see is port capacity, this case are 10gbps ports so that's not likely an issue.
On Tue, Feb 16, 2021, 3:22 PM Adam Moffett <dmmoff...@gmail.com> wrote: > I wouldn't assume any gain in efficiency. I think you're saying the two > or more VLAN's each have their default gateway on logical VLAN interfaces > under the same physical interface. A packet coming in one and out another > still has to have the destination IP compared to the routing table to find > a matching route. It's tempting to imagine that it made a hairpin turn and > never left the interface, but a more realistic block diagram would show the > packet going through the interface to the system CPU and then back out. > Whether it went out the same physical interface or a different one > shouldn't change anything......or so I'd assume. > > > On 2/16/2021 4:12 PM, Steve Jones wrote: > > Is there any component of the routing stack that it skips through since it > doesnt traverse interfaces? On the backhaul side of things traffic just > flows without any policy or anything, I have INPUT chain rules and things > for the site LAN So I dont think there is much that would happen to miss. I > dont know though. > > Im going to have these all turned into BMUs so I dont know what happens > there either, have to make sure powercode isnt dicking with traffic > > On Tue, Feb 16, 2021 at 11:10 AM Josh Luthman <j...@imaginenetworksllc.com> > wrote: > >> It's packet processing. However much it needs to do. If you're just >> tagging a VLAN through the device I think that can be done on the switch >> level and it can do wire speed. If you're doing OSPF between two >> interfaces, you're processing every packet and will need a bigger CPU for >> more traffic. >> >> Asking good questions means you're not a dumbass :) >> >> Josh Luthman >> 24/7 Help Desk: 937-552-2340 >> Direct: 937-552-2343 >> 1100 Wayne St >> Suite 1337 >> Troy, OH 45373 >> >> >> On Mon, Feb 15, 2021 at 10:07 PM Steve Jones <thatoneguyst...@gmail.com> >> wrote: >> >>> In my case we are probably going to be sticking with Mikrotik for now, >>> but I assume its similar for most hardware. >>> >>> Where is the "load" when routing VLANs on the same physical port. >>> >>> Backhauls of any capacity are almost all moving to SFP+ to support >>> gigabit and up capacity. APs are starting to come with cages as well. >>> >>> We dont have the cage count. Looking at our options, combined with the >>> limitations powercode imposes, we have decided to stick with the RB4011 >>> moving forward for our site routers and and external switch for our SFP+ >>> cage count, probably something like CRS309 or something of that nature as >>> long as we stay under 7 SFP+ needed and trunk to the router via its single >>> SFP+ >>> >>> so most of the routing will happen on the same physical port with the >>> exception of the remaining copper backhauls. >>> We will probably use our current procurves until they die off to add >>> more LAN copper for APs where needed, but there may be APs like Medusas on >>> the CRS as well. >>> >>> we currently only have a total of 2 Gbps upstream capacity, that will >>> probably double over the next year or so, so its not like we are running >>> massive bandwidth, we currently max around 100-150k pps on our heaviest CCR >>> so we wont hit that cap soon. >>> >>> I dont know how the test results throughput is calculated, is that >>> distributed across al ports, its that the capability per port? a mix of >>> them? >>> I usually try to keep backhauls and LAN on different switch chips, but >>> what will be handling the traffic when most of it is on the same physical >>> port? >>> >>> I wont feel bad if you call me a dumbass for not knowing this type of >>> shit this far into the game, I have thick skin, but would still like to >>> understand whats happenning and what kind of issues Im about to cause myself >>> -- >>> AF mailing list >>> AF@af.afmug.com >>> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >>> >> -- >> AF mailing list >> AF@af.afmug.com >> http://af.afmug.com/mailman/listinfo/af_af.afmug.com >> > > -- > AF mailing list > AF@af.afmug.com > http://af.afmug.com/mailman/listinfo/af_af.afmug.com >
-- AF mailing list AF@af.afmug.com http://af.afmug.com/mailman/listinfo/af_af.afmug.com
