argus-3.x request (forwarded)

[Peter Van Epp]

On Thu, Feb 11, 2010 at 05:17:13PM -0500, Carter Bullard wrote:
> Well, maybe it will be better just to talk about what is required.
> 

	There is an excellent chance that will be faster for sure :-)

> So the goal is to differentiate the same flow but in different
> tunnels,  I think I need to add all encapsulations to the flow key,
> or at least parts of all the encapsulations, because each encaps
> is a functional tunnel.  
> 
> I need to keep track of the order of the encapsulations, as encapsulation
> scoping isn't commutative.  Ethernet header -> VLAN tag -> IP  isn't the
> same as IP header -> Ethernet header -> VLAN tag
> 

	While we hadn't gotten as weird (at least knowingly :-)) as tunneling
VLANs, it would certainly be possible. 

> Bidirectionality doesn't hold true for some encapsulations.
> MPLS is a half-duplex service, as the return MPLS labels
> don't have any relationship to each other.
> 

	Unfortunatly the acronym MPLS is about as much as I know about it :-)
We weren't running it although the local Gigapop has used it in their core.


> For MPLS, adding all the stacked MPLS labels is important,
> but there is no "bi-directional" aspect to MPLS, so I'll need
> to track the source and destination encapsulation identifiers
> separately.   Bidirectionality can be tracked at the highest
> level Transport header, like we're doing now.
> 
> Same holds true for VLAN tags?  Can I get one half of a flow in
> one VLAN, and the return traffic for the flow in another VLAN?

	I wouldn't think so, the case I know of is both way flow to the same
5 tuple on vlan A and the identical (except for new MAC addresses) flow on
VLAN B on the same physical link due to one armed routing. A similar situation
occurs (and used to break, or at least not do what I expected which may not be
exactly the same thing :-)) with overlayed subnets where for instance 
192.168.1.0/24 and 192.168.3.0/24 are both overlayed on the same physical
wire. If host 192.168.1.1 talks to 192.168.3.10 argus should see dual flows
192.168.1.1 to 192.168.1.254 (the router) and the same flow from 192.168.3.254
to 192.168.3.10. This is the case that used to break although I don't remember
exactly how it broke (which is part of the reason to try it on a test network
again and see what happens :-)). 

> Is it possible for the return traffic to not be in a VLAN? Is that possible?
> 
> What do you think?
> 

	Its certainly possible, the only question would be is it correct :-).
On our Enterasys switches you can specify on the switch CLI what VLANs egress
out a port, and with sufficient skill (because I've seen it done :-)) you can
egress both tagged and untagged frames out the same port. I'm not sure there
is a sensible reason for doing that, but it is at least possible :-). I'm
pretty sure it wasn't intentional on the port I was looking at, but that 
doesn't mean there isn't a case were it would make sense. The usual reason for
us to go from VLAN to untagged is on the boundary between our network and a 
departmental network (where we don't control the VLAN tagging on their network
and don't want them to be able to inject tags in to our network) so I'm pretty
sure that one was just a configuration error. 

Peter Van Epp