@Douglas Generous wrote:
First I need to address a supposition that is being made about pppoe. Pppoe does not mean double nat nor does routed mode in the epmp-sm.
Nobody said either one of those things necessitated double-NAT. This (pre)supposition was not made by anybody. Maybe I missed something, but I think you might be reading things into other people's posts that isn't there.
Pppoe is an access control method that allows control over how a subscriber can connect and at what times/rates. IPoE is an updated version of this. IPoE is not pppoe but they are very similar.
...uh, no, IPoE is not an "updated" version of PPPoE. The way people use the term "PPPoE", they probably should instead be saying IPoPPPoE (IP over PPP over Ethernet), because that's almost surely the only thing they use PPPoE for: encapsulating IP datagrams with PPP, but over an Ethernet network instead of a serial interface. IPoE *literally* just means IP datagrams being encapsulated in an Ethernet frame...as in, exactly what you would see on your typical Ethernet-based LAN. That's it. PPPoE is kind of a "layer 2.5" thing that sits in between the IP packet and the Ethernet frame. And yes, it's typically used as a means of access control, but that's kinda beside the point.
Routed mode does not mean nat, [...]
[snip long explanation of IP routing]
Again, nobody said it did. And sure, of course you can disable NAT mode in the SM, and then route a /30 or other prefix to it, either while using PPP or not. We do this all the time for customers of ours that need multiple routables (/29 or shorter prefix).
So if my goals were to 1) use PPPoE, 2) have ePMP QoS honor the DSCP bits of IP packets flowing through the SM, and 3) not use any NAT at all, then sure, using the tools available to us today, I could put the SM in router mode, have it act as the PPPoE client, and route a /30 to it. But that would be a waste of good IPv4 space, especially if I did it for every customer (4 IPs extra per), now wouldn't it?
Now on to the next point.
Their are perfectly valid reasons to bridge an SM.
Yes, there are, but you only listed reasons why you might want *some* of your SMs in bridge mode. My point is that we want *all* of ours in bridge mode because in our experience, the routing engines in most vendors' CPE models suck. Plus, we also prefer bridge mode so that we can reduce the homogenous surface area on our network available to worms attacking zero-day security flaws that are discovered in said CPEs. I don't want any of our SMs that we buy and use from any of our vendors to be reachable from the internet, period. (Again, unfortunately not realistic on the LTE side of things right now, so we're doing what we can with what we've got.)
Wow inside ppp can be made to work but the OP was asking at the SM in bridge mode.
As was I. (And I assume "wow" was a typo?)
The SM does not do this and is not intended to do this in that mode. [...] But if anything tries to interfere with the pppoe stream then it breaks. DPI can see what is in the packet but then all you can do is queue the stream to let higher priority packets through. If you try to lower available bandwidth then the stream will need to drop and reconnect.
I don't think you're picking up what some of us in this thread are throwing down.
Correct, the SM does not do this currently. But you talk about this as if it is not even technically feasible. I am directly challenging that claim.
We know that it is technically feasible because PMP450 already does this (QoS bridged PPPoE frames based on the encapsulated IP packet's DSCP)!
Which means that your claim that nothing mid-stream (like a bridge!) is allowed to "interfere" with the timing of the delivery of PPPoE payloads can't be correct, because there is already another platform out there that has demonstrated it can be done! Also, if you simply look at the structure of a PPPoE session frame, it's clear that the only kind of "state" it keeps track of is the PPPoE session ID itself, not the state of packets that are being encapsulated by it...the PPPoE header does not have "packet sequence" numbering included in it at all whatsoever. So it does not matter if data payloads encapsulated by PPPoE arrive at their destination "out of order" (or, rather, it doesn't make any MORE of a difference with PPPoE-encapsulated IP than it does with plain IP traffic).
We also know that ePMP SM can already QoS bridged IP(oE) datagrams.
So, again, the logic seems simple:
/* ...in the middle of existing bridge & QoS code, add... */
if ( frame.ethertype == 0x8864 ) {
frame.payload_pointer += 8;
}
/* continue on with QoS DSCP check */
This might require rummaging around in the Linux kernel itself to accomplish, but it is hardly complicated nor CPU-intensive. But if you want to call looking ahead by 8 octets when a PPPoE Session frame is seen in the bridge "deep packet inspection", then knock yourself out...
-- Nathan