Age | Commit message (Collapse) | Author |
|
makes input bytes and packets consistent
|
|
this let's input processing bypass ifiqs. there's a performance
benefit from this, and it will let me tweak the backpressure detection
mechanism that ifiqs use without impacting on a stack of virtual
interfaces.
ive tested all of these except mpw, which i will end up testing
soon anyway.
|
|
i need to come back to this and make it flow a bit better, but this
is a good start.
|
|
no functional change.
|
|
conditional timeout_barrier(9).
OK kn@ dlg@
|
|
ok claudio@ dlg@
|
|
ok dlg@
|
|
There's nothing underneath the tunnels that needs configuration,
so there's no point in keepign track of configured multicast
addresses. We will at least save a bit of memory.
|
|
ENETRESET in hardware drivers means you should reprogram the hardware.
There's no hardware to reprogram, so just turn it into 0 on the way
out.
|
|
calls to m_get/M_GET calls because M_MOVE_PKTHDR() is initialising
the pkthdr and so it is not needed when allocation the header.
OK bluhm@
|
|
this is a step toward better rfc6040 support
ok claudio@
|
|
no functional change.
|
|
the mbuf prio will still be set according to the llprio value, but the
tos on the packet may be forced to a specific number by txprio
|
|
rfc1853 is about IP in IP Tunneling. rfc2003 about IP Encapsulation
within IP agrees.
|
|
for l3 interfaces (gre and mgre), allow txprio from the payload,
the mbuf, or a hardcoded value. for l2 interfaces (egre, ngre, and
eoip), get txprio from the mbuf or a hardcoded value.
ok claudio@
|
|
|
|
|
|
the llprio is already used to set the gre and eoip packet tos/tclass,
but it was queued at the default prio before this.
|
|
llprios are valued 0 to 7, while the ip tos/dscp/tclass is an 8 bit
value. fortunately the high 3 bits map nicely to the llprio values,
so we shift the llprio into place when generating the keepalive
frames. the llprio is defaulted to the value that cisco uses for
their gre keepalives.
|
|
the timeout gets configured instead of gre_up().
this avoids complex gre_ioctl() ordering rules and
enables the sc_ka_hold timeout before the first packet
is received.
from markus@
|
|
from markus@
|
|
|
|
check sc_tunnel.t_af for AF_UNSPEC, otherwise we panic in gre_encap()
from markus@
|
|
gre_keepalive_send() should re-schedule immediately, otherwise we
stop sending keepalive on temporary mbuf shortage or if the
configuration is incomplete.
from markus@
|
|
The packet processing done after the protocol detection effectively
gets thrown away by the keepalive handling, so this saves some time,
and avoids confusing tcpdump on the interface. Keepalives the driver
transmits aren't made available for bpf, so taking it away from the
receive side is consistent.
discussed with and tested by markus@
|
|
this gives ipv6 handling equivalent the tos stuff in ipv4.
ok visa@ benno@
|
|
properly. This had caused an panic when the mbuf pointer is updated.
Found by IIJ.
ok dlg
|
|
it is sort of like egre(4), but different enough to warrant separate
handling. more specifically, eoip sits under gre 1, not 0, and has
it's own protocol id (0x6400). the gre key field is mandantory (the
rest cannot be set) which is split into a 16 bit length field and
a 16 bit tunnel id. lastly, it has a keepalive mechanism where peers
send 0 length packets as hellos to each other periodically, which
has no equivalent in egre(4) and is different to the gre(4) keepalives.
ok sthen@
|
|
ok jsg@
|
|
according to small bits of cisco doco, multicast can be implemented
on mgre using head-end replication. that isnt implemented, but the
flags do allow ipv6 addresses to be added to the interface.
|
|
|
|
this relies on ifconfig tunneladdr
|
|
ok mpi@
|
|
suggested by mpi@
|
|
in practice this means NET_ASSERT_LOCKED() near the lists and trees
holding the different types of gre interfaces.
suggested by mpi@
|
|
mgre is different to gre in that the tunnel only needs configuration
for a local address, and the address inside the tunnel is configured
on it is a subnet. other addresses on that subnet get mapped to a
tunnel endpoint and send there.
at the moment that mechanism is the routing table, using non-gateway
host routes with the tunnel endpoint as the gateway address.
the tunnel address configuration is ugly and confusing atm, but
should improve soon.
ok mpi@ who has some suggestions i can do in the tree.
|
|
|
|
|
|
|
|
|
|
NVGRE is short for Network Virtualization Using Generic Routing
Encapsulation.
it provides an overlay ethernet network with multiple ip peers,
rather than a tunnel to a single peer like egre(4) provides. unlike
egre the vnetid is mandantory and always 24 bits. it offers similar
functionality to vxlan(4).
|
|
|
|
|
|
internet control, so we can too.
|
|
when enabled, the 32bit key on gre a packet is split into a 24bit
key and an 8 bit flow id. this allows better use of multipath links
if the intermediate routers feed the gre key into their hashing
algorithms. because gre can encapsulate pretty much anything, it
can be non-trivial for a router to reach into a payload to harvest
entropy for feeding into a hashing algorithm. having the endpoints
do it and feed it into the gre header is a lot simpler.
this allows interoperationg with cisco gre tunnels with key entropy
enabled. this was tested against a csr1000v.
also, this arrangement coincides with how nvgre works, so it paves
the way for supporting that protocol.
right now the driver relies on the flowid in mbufs to populate the
packet field. this generally means that pf should be enabled to
provide the flowid.
|
|
|
|
makes the code a bit more straightforward
|
|
it's new so there's no existing configs to be compat with.
|
|
this also changes the wccp handling to peek into it's payload to
determine whether it is wccp 1 or 2. wccp1 says the gre header is
followed by ipv4, while wccp2 says there's a small header before
the ipv4 packet. the wccp2 header cannot have 4 in the first nibble,
while ipv4 must have 4 in the first nibble. the code now looks at
the nibble to determine whether it should strip the wccp2 header
or not.
|
|
this lets us look up the gre(4) interface before looking at the
protocols it might be carrying.
|