ebtables & VLAN redirect

ebtables & VLAN redirect

[Anatoly Muliarski]

Hi list,

I have a lot of VLANs( eth1.100-eth1.200) and I need to redirect
specific IP frames arrived on them to VLAN eth1.9 on L2 level( as I
cannot use routing for them ). The simple way is to create a bridge
from all VLANs and filter out redirections to
unwanted(eth1.100-eth1.200) VLANs.
But this may cause preformance issues. Is there a finer solution?

-- 
Best regards
Anatoly Muliarski

Re: ebtables & VLAN redirect

[Grant Taylor]

Anatoly Muliarski wrote:
> I have a lot of VLANs( eth1.100-eth1.200) and I need to redirect
> specific IP frames arrived on them to VLAN eth1.9 on L2 level( as I
> cannot use routing for them ). The simple way is to create a bridge
> from all VLANs and filter out redirections to
> unwanted(eth1.100-eth1.200) VLANs.

That will work.

Do you need to do so for all your VLANs, or just some of them?

> But this may cause preformance issues. Is there a finer solution?

Could you get proxy ARP to work?

In other words, why selectively extend your broadcast domains in to the 
other when you might be able to extend individual systems in to multiple 
broadcast domains (in a manner of speaking).

If you aren't modifying frames as they pass through your bridge, and the 
only real thing that takes time to look through is your EBTables rules, 
I don't think you will have a problem.  -  I've run multiple older 
slower systems (P-II 233) doing similar things (and bi-directional 
NATing of source and destination MAC addresses) for a multi-megabit DSL 
connection with out any problems.  -  If you are worried about speed, 
pick up a current low end workstation computer with with a decent 
network card.

I'd say try it and see if the problem you are thinking about will even 
have any impact on the equipment you are using.

Depending on the amount of traffic you are working with, I'd suggest 
gigabit connections to the switch.  If it's really a lot of traffic, 
multiple connections to segregate the traffic.



Grant. . . .

Re: ebtables & VLAN redirect

[Anatoly Muliarski]

2010/6/26 Grant Taylor <gtaylor@riverviewtech.net>:
> Anatoly Muliarski wrote:
>>
>> I have a lot of VLANs( eth1.100-eth1.200) and I need to redirect
>> specific IP frames arrived on them to VLAN eth1.9 on L2 level( as I
>> cannot use routing for them ). The simple way is to create a bridge
>> from all VLANs and filter out redirections to
>> unwanted(eth1.100-eth1.200) VLANs.
>
> That will work.
>
> Do you need to do so for all your VLANs, or just some of them?

Thank you for your response.

Unfortunately, I need to redirect the traffic from all VLANs. In other
words, the task comes to selective redirecting of the traffic from all
VLANs to a specified one. The redirecting must be unidirected, only
for the traffic that comes from all VLANs.

>
>> But this may cause preformance issues. Is there a finer solution?
>
> Could you get proxy ARP to work?

Yes, it works now, but for the other purpose.

>
> In other words, why selectively extend your broadcast domains in to the
> other when you might be able to extend individual systems in to multiple
> broadcast domains (in a manner of speaking).

That would work but I need to redirect traffic that is not destined to
VLAN 9 and ARP-proxy trick does not work for this case.

>
> If you aren't modifying frames as they pass through your bridge, and the
> only real thing that takes time to look through is your EBTables rules, I
> don't think you will have a problem.  -  I've run multiple older slower
> systems (P-II 233) doing similar things (and bi-directional NATing of source
> and destination MAC addresses) for a multi-megabit DSL connection with out
> any problems.  -  If you are worried about speed, pick up a current low end
> workstation computer with with a decent network card.
>
> I'd say try it and see if the problem you are thinking about will even have
> any impact on the equipment you are using.
>
> Depending on the amount of traffic you are working with, I'd suggest gigabit
> connections to the switch.  If it's really a lot of traffic, multiple
> connections to segregate the traffic.

Thanks for the ideas. I'll try it. The main problem is to avoid
unnecessary bridging attempts for all VLANs( as it would waste CPU
time for try to transmit a packet to a hundred VLAN ).
Another way is to write a target extension to ebtables to replace a
vlan tag to a desired one, but as I need to do it selectively I need
ebtables' capabilities to analyze vlan-tagged packets and there are no
ones ...
Or to write something like a udp-broadcast-relay daemon...

-- 
Best regards
Anatoly Muliarski

Re: ebtables & VLAN redirect

[Grant Taylor]

Anatoly Muliarski wrote:
> Thank you for your response.

You are welcome.

> Unfortunately, I need to redirect the traffic from all VLANs. In 
> other words, the task comes to selective redirecting of the traffic 
> from all VLANs to a specified one. The redirecting must be 
> unidirected, only for the traffic that comes from all VLANs.

Will you please provide an example of what redirection you are talking 
about?

Remember that you can set a default policy of DROP in your BROUTING 
chain to cause the packets to be routed like normal.  So any frames that 
you don't want bridged will simply be routed like normal.  There by only 
bridging the frames that you want to.

> Yes, it works now, but for the other purpose.

Ok.

> That would work but I need to redirect traffic that is not destined 
> to VLAN 9 and ARP-proxy trick does not work for this case.

So you are going to have to intercept the traffic and alter the 
destination MAC (and possibly IP) address(es)?

I believe that EBTables can do that.  If not, you can probably have 
IPTables work on bridged frames, and I know that it will do that.

> Thanks for the ideas. I'll try it. The main problem is to avoid 
> unnecessary bridging attempts for all VLANs( as it would waste CPU 
> time for try to transmit a packet to a hundred VLAN ). Another way is 
> to write a target extension to ebtables to replace a vlan tag to a 
> desired one, but as I need to do it selectively I need ebtables' 
> capabilities to analyze vlan-tagged packets and there are no ones ...

I'm still not sure that you can't do what you want to do with EBTables 
and / or IPTables.

Remember that EBTables will learn where MAC addresses are and won't 
flood frames out (go in to dumb hub mode).

> Or to write something like a udp-broadcast-relay daemon...

I don't think you will be bridging too many packets.  (That is unless I 
really misunderstand what you are wanting to do.)

Can you provide an example (sanitized if need be) of what you are trying 
to do?  Including (hypothetical) source and destination MAC and IP 
addresses on either side of the bridge?



Grant. . . .

Re: ebtables & VLAN redirect

[Anatoly Muliarski]

2010/6/28 Grant Taylor <gtaylor@riverviewtech.net>:
> Will you please provide an example of what redirection you are talking
> about?

Unfortunately, I have a set of tasks to cope with.
1. UDP broadcast relaying for specific ports from specific VLANs - on
second thought I've decided to use udp-broadcast-relay as it's the
simplest way.
2. Multicast feeding and IGMP exchange snooping - I tried to avoid
using igmpproxy but probably I should use it.
3. Mirroring specific sessions to VLAN 9 - and I can postpone this
task for the future.

>
> Remember that you can set a default policy of DROP in your BROUTING chain to
> cause the packets to be routed like normal.  So any frames that you don't
> want bridged will simply be routed like normal.  There by only bridging the
> frames that you want to.

Yes, I knew about it - very nice feature.

>> That would work but I need to redirect traffic that is not destined to
>> VLAN 9 and ARP-proxy trick does not work for this case.
>
> So you are going to have to intercept the traffic and alter the destination
> MAC (and possibly IP) address(es)?

For mirroring purpose I have to alter destination MAC and I can do
that in POSTROUTING chain.
Other tasks use broadcast/multicast destination addresses so I do not
need to alter them.

>
> I believe that EBTables can do that.  If not, you can probably have IPTables
> work on bridged frames, and I know that it will do that.
>
> I'm still not sure that you can't do what you want to do with EBTables and /
> or IPTables.
>
> Remember that EBTables will learn where MAC addresses are and won't flood
> frames out (go in to dumb hub mode).
>
> I don't think you will be bridging too many packets.  (That is unless I
> really misunderstand what you are wanting to do.)

Bridging is a good idea, but its current implementation lacks some
features important to me - as impossibility to limit traffic
directions between bridge devices and the fact that a network device
can belong to one bridge only.

>
> Can you provide an example (sanitized if need be) of what you are trying to
> do?  Including (hypothetical) source and destination MAC and IP addresses on
> either side of the bridge?

In two words :). All user VLANs(eth1.100-eth1.200) have IP belonging
to one subnet( but sometimes to other ) and they can communicate each
other by using proxy-arp trick under control of the router. And now I
need to extend capabilities of this communication as I stated above.
Owing to talking with you and thinking on the problems I understand my
tasks clearer.
Grant, thank you for your support.

-- 
Best regards
Anatoly Muliarski

Re: ebtables & VLAN redirect

[Grant Taylor]

On 06/28/10 12:33, Anatoly Muliarski wrote:
> Unfortunately, I have a set of tasks to cope with.

Not a problem.

> 1. UDP broadcast relaying for specific ports from specific VLANs - on 
> second thought I've decided to use udp-broadcast-relay as it's the 
> simplest way.

Ok...  Remember that the simplest way may not always be the best way.

> 2. Multicast feeding and IGMP exchange snooping - I tried to avoid 
> using igmpproxy but probably I should use it.

> 3. Mirroring specific sessions to VLAN 9 - and I can postpone this 
> task for the future.

Please clarify what you are meaning by "mirroring specific sessions".

> For mirroring purpose I have to alter destination MAC and I can do 
> that in POSTROUTING chain.

It sounds like you are NATing at the data layer.

> Other tasks use broadcast/multicast destination addresses so I do not 
> need to alter them.

Ok.

> Bridging is a good idea, but its current implementation lacks some 
> features important to me - as impossibility to limit traffic 
> directions between bridge devices and the fact that a network device 
> can belong to one bridge only.

Please clarify "impossibility to limit traffic direction between bridge 
devices".

It is trivial to allow bridging one way while blocking it the other way.

I.e. set an EBTables policy to DROP and only allow bridging the 
direction you want.

VID:100 --> VID:9
VID:101 --> VID:9
VID:102 --> VID:9
...
VID:199 --> VID:9

Bridging does not have to be by-directional.  You can easily make 
EBTables not bridge the traffic.

> In two words :). All user VLANs(eth1.100-eth1.200) have IP belonging 
> to one subnet( but sometimes to other ) and they can communicate each 
> other by using proxy-arp trick under control of the router. And now I 
> need to extend capabilities of this communication as I stated above. 
> Owing to talking with you and thinking on the problems I understand 
> my tasks clearer.

It may be my mis-understanding, but I'm still not seeing why you can't 
do this in EBTables using bridging.

If you bridge all your VLANs together and configure EBTables to filter 
the traffic, I don't see what the problem will be.

All your layer 3 traffic will behave as if it is on one large network, 
passing through the bridge with out the need for modification.  Granted, 
you can modify the traffic if you /want/ to, but I don't see the /need/ 
for it.  At least based on my (mis)understanding.

> Grant, thank you for your support.

You are welcome.

Let me ask you this:

Do you want your different user VLANs to be able to communicate with 
each other?  (Inter user VLAN communications)

How would this scenario work for you:

  - Bridge all the user VLANs and the VLAN 9 together.
  - Configure the bridge to drop the frames by default.
  - Configure the bridge to selectively bridge the frames that you want to.
  - Optionally alter the bridged frames if you want to.

I think I did something similar to what you are wanting to do a number 
of years ago.  I bridged about 40 different VLANs (sharing one IP 
subnet) together and configured them so that they could not talk with 
each other (preventing the spread of virus / worms) but so that they 
could talk to the router that was on a different VLAN that was part of 
the bridge.  In the process I had to modify the MAC address of traffic 
b/c the switch that was being used had a flaw where it could not see the 
same MAC address on more than one VLAN.  This has been in place and 
working just fine for a number of years.  Originally it started out on a 
P-II 233 MHz system with 128 MB of memory and it was able to do it with 
out any problems.  The only reason we replaced the box was because it 
was physically old and we did not want the hardware to dye on us.  I 
ended up copying the EBTables scripts from the old system to the new 
system and made very minor modifications to get everything to work 
(essentially as it was) with out any problems.



Grant. . . .

Re: ebtables & VLAN redirect

[Anatoly Muliarski]

2010/6/28 Grant Taylor <gtaylor@riverviewtech.net>:
>> 3. Mirroring specific sessions to VLAN 9 - and I can postpone this task
>> for the future.
>
> Please clarify what you are meaning by "mirroring specific sessions".

Session may be not fully correct word - more precisely it should
understand as IP traffic flows specified by address:port pairs to dump
the traffic.

>> Bridging is a good idea, but its current implementation lacks some
>> features important to me - as impossibility to limit traffic directions
>> between bridge devices and the fact that a network device can belong to one
>> bridge only.
>
> Please clarify "impossibility to limit traffic direction between bridge
> devices".
>
> It is trivial to allow bridging one way while blocking it the other way.
>
> I.e. set an EBTables policy to DROP and only allow bridging the direction
> you want.
>
> VID:100 --> VID:9
> VID:101 --> VID:9
> VID:102 --> VID:9
> ...
> VID:199 --> VID:9
>
> Bridging does not have to be by-directional.  You can easily make EBTables
> not bridge the traffic.

Your explanation is correct BUT in current bridging model there would
be a hundred attempts to flood ALL broadcast/multicast traffic
received from every bridge port. Yes, I can filter them out by using
ebtables rules, but this unnecessary attempts will waste CPU time.
Writing "to limit traffic direction between bridge devices" I meant
there is no support to exclude attempts of flood to ALL ports by
limiting a direction of flooding in the description of a bridge
device.

> It may be my mis-understanding, but I'm still not seeing why you can't do
> this in EBTables using bridging.
>
> If you bridge all your VLANs together and configure EBTables to filter the
> traffic, I don't see what the problem will be.
>
> All your layer 3 traffic will behave as if it is on one large network,
> passing through the bridge with out the need for modification.  Granted, you
> can modify the traffic if you /want/ to, but I don't see the /need/ for it.
>  At least based on my (mis)understanding.

OK bridging will work, but I am afraid to meet performance issues
afterwards as I stated above.

> Let me ask you this:
>
> Do you want your different user VLANs to be able to communicate with each
> other?  (Inter user VLAN communications)
>
> How would this scenario work for you:
>
>  - Bridge all the user VLANs and the VLAN 9 together.
>  - Configure the bridge to drop the frames by default.
>  - Configure the bridge to selectively bridge the frames that you want to.
>  - Optionally alter the bridged frames if you want to.
>
> I think I did something similar to what you are wanting to do a number of
> years ago.  I bridged about 40 different VLANs (sharing one IP subnet)
> together and configured them so that they could not talk with each other
> (preventing the spread of virus / worms) but so that they could talk to the
> router that was on a different VLAN that was part of the bridge.  In the
> process I had to modify the MAC address of traffic b/c the switch that was
> being used had a flaw where it could not see the same MAC address on more
> than one VLAN.  This has been in place and working just fine for a number of
> years.  Originally it started out on a P-II 233 MHz system with 128 MB of
> memory and it was able to do it with out any problems.  The only reason we
> replaced the box was because it was physically old and we did not want the
> hardware to dye on us.  I ended up copying the EBTables scripts from the old
> system to the new system and made very minor modifications to get everything
> to work (essentially as it was) with out any problems.

Very interesting.
Thank you for your advise, It worth to employ ebtables in solving my tasks.
And I have met the same problem with MACs in other project and I had
to generate different source MACs for different VLANs and eventually I
had to replace the switch to cope with the problem of matching
destination MACs for different VLANs.

-- 
Best regards
Anatoly Muliarski

Re: ebtables & VLAN redirect

[Grant Taylor]

On 06/29/10 13:15, Anatoly Muliarski wrote:
> Session may be not fully correct word - more precisely it should 
> understand as IP traffic flows specified by address:port pairs to 
> dump the traffic.

So you are wanting to mirror specific flows that are passing through 
your system to VLAN 9.

What interfaces are these flows being passed through?  The bridge and 
another (virtual) interface?  In other words, what would be an example 
of an incoming interface and an out going interface?  Or is this traffic 
making it to your system because it is multicast / flooded on each VLAN?

> Your explanation is correct BUT in current bridging model there would 
> be a hundred attempts to flood ALL broadcast/multicast traffic 
> received from every bridge port. Yes, I can filter them out by using 
> ebtables rules, but this unnecessary attempts will waste CPU time.

Ok.  Just my opinion, but if this system is being designed to do this 
(presuming there are not other options) I'd make sure that the CPU was 
scaled to function with the amount of traffic.

> Writing "to limit traffic direction between bridge devices" I meant 
> there is no support to exclude attempts of flood to ALL ports by 
> limiting a direction of flooding in the description of a bridge 
> device.

Ok...  Now it sounds like you are wanting some more advanced features 
(read things that purposefully break standards in some situations) like 
broadcast storm protection.

> OK bridging will work, but I am afraid to meet performance issues 
> afterwards as I stated above.

Maybe, maybe not.

> Very interesting.

*nod*

> Thank you for your advise, It worth to employ ebtables in solving my 
> tasks. And I have met the same problem with MACs in other project and 
> I had to generate different source MACs for different VLANs and 
> eventually I had to replace the switch to cope with the problem of 
> matching destination MACs for different VLANs.

I'm starting to wonder if your system isn't being used as a traditional 
piece of network infrastructure equipment (router / switch / bridge). 
Rather if you are trying to make a utility that will ""extend a 
monitoring package that is designed to monitor one VLAN in such a way 
that it can monitor multiple VLANs.  Or at least bridge the traffic you 
want to monitor from multiple VLANs down to one VLAN that your 
application can monitor.

If this is the case, and you are using separate VLANs to avoid network 
congestion problems, I agree that bridging might not be the best option 
here.

In this case, I'd look at doing something that will cause your system to 
receive the traffic you are interested in and pass on to the monitoring 
application.  -  I'm guessing that an application layer gateway would 
probably be best at doing this.

The simple fact that you have the amount of incoming traffic that you 
want to filter and forward a subset of implies that there will be CPU 
time spent analyzing which traffic to forward.



Grant. . . .

Re: ebtables & VLAN redirect

[Grant Taylor]

On 06/29/10 14:29, Grant Taylor wrote:
> The simple fact that you have the amount of incoming traffic that you 
> want to filter and forward a subset of implies that there will be CPU 
> time spent analyzing which traffic to forward.

Along these lines, I have what some might consider a devious idea.

Create a bridge for each VLAN.  That will give you the VLAN interface 
and it's associated bridge interface.  Then bridge the bridge interfaces 
in to a larger bridge.

Using all the smaller bridges will keep the possible rules that you need 
to match smaller, thus less load on the CPU.  You could also turn down 
the VLANs individual bridge when you didn't want to monitor any traffic 
on it, thus reducing the load further.

So, you would end up with a topology somewhat like this:

eth0.101 <-> br101 <-> br9
eth0.102 <-> br102 <-> br9
eth0.103 <-> br103 <-> br9 <-> eth1.9
...
eth0.199 <-> br199 <-> br9

In this case, br9 is nothing more than a collector from all the other 
bridges.

It's the interaction between eth0.<VID> and br<VID> that has to do the 
filtering.

When you don't want to monitor traffic on say, eth0.123, simply remove 
it from br123.  Doing so will cause br123 to disable (but not remove) 
its self which will cause br9 to disable the port that is br123.  - 
Then when you want to monitor eth0.123, re-add it to br123, causing 
br123 to re-enable, causing br9 to re-enable br123's port.

Using br9 to aggregate all the VLANs together will also make it easier / 
less load to make sure that you don't have inter-VLAN communications 
because only the traffic you are interested in will make it that far, 
not all the traffic that you are talking about.  Seeing as how there 
will be much less traffic, matching the EBTables rules to see what can 
talk to what (for br9) will be much less load on the system.

Something to think about.



Grant. . . .

Re: ebtables & VLAN redirect

[/dev/rob0]

On Tue, Jun 29, 2010 at 02:31:02PM -0500, Grant Taylor wrote:
> In this case, br9 is nothing more than a collector from all the 
> other bridges.

I would only suggest that you call it "br549".

To those who don't get the joke, I apologize.

To those who DO get the joke, I apologize.
-- 
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header

Re: ebtables & VLAN redirect

[Grant Taylor]

/dev/rob0 wrote:
> I would only suggest that you call it "br549".

*chuckle*

> To those who DO get the joke, I apologize.

*sigh*



Grant. . . .

Re: ebtables & VLAN redirect

[Anatoly Muliarski]

2010/6/29 Grant Taylor <gtaylor@riverviewtech.net>:
> On 06/29/10 14:29, Grant Taylor wrote:
>>
>> The simple fact that you have the amount of incoming traffic that you want
>> to filter and forward a subset of implies that there will be CPU time spent
>> analyzing which traffic to forward.
>
> Along these lines, I have what some might consider a devious idea.
>
> Create a bridge for each VLAN.  That will give you the VLAN interface and
> it's associated bridge interface.  Then bridge the bridge interfaces in to a
> larger bridge.
>
> Using all the smaller bridges will keep the possible rules that you need to
> match smaller, thus less load on the CPU.  You could also turn down the
> VLANs individual bridge when you didn't want to monitor any traffic on it,
> thus reducing the load further.
>
> So, you would end up with a topology somewhat like this:
>
> eth0.101 <-> br101 <-> br9
> eth0.102 <-> br102 <-> br9
> eth0.103 <-> br103 <-> br9 <-> eth1.9
> ...
> eth0.199 <-> br199 <-> br9
>
> In this case, br9 is nothing more than a collector from all the other
> bridges.
>
> It's the interaction between eth0.<VID> and br<VID> that has to do the
> filtering.
>
> When you don't want to monitor traffic on say, eth0.123, simply remove it
> from br123.  Doing so will cause br123 to disable (but not remove) its self
> which will cause br9 to disable the port that is br123.  - Then when you
> want to monitor eth0.123, re-add it to br123, causing br123 to re-enable,
> causing br9 to re-enable br123's port.
>
> Using br9 to aggregate all the VLANs together will also make it easier /
> less load to make sure that you don't have inter-VLAN communications because
> only the traffic you are interested in will make it that far, not all the
> traffic that you are talking about.  Seeing as how there will be much less
> traffic, matching the EBTables rules to see what can talk to what (for br9)
> will be much less load on the system.
>
> Something to think about.
>

A nice idea.
I have thought about it a bit earlier.
BUT linux implementation of bridging has two limitations that makes it
impossible:
1. There cannot be nested bridge devices.
2. Each device can belong to only one bridge device.

Eventually I have come to understanding that my problem has no fine
solution with no risks for performance. Partially I can solve it on
application layer, partially by using bridging.
And talking with you enlightened me on the ways of doing it.
Thanks for your efforts and ideas.

-- 
Best regards
Anatoly Muliarski

Re: ebtables & VLAN redirect

[Grant Taylor]

On 06/30/10 15:54, Anatoly Muliarski wrote:
> A nice idea.

;-)

> I have thought about it a bit earlier.

Nice to know that I'm either not (too) crazy or that I'm not alone in my 
thought process.

> BUT linux implementation of bridging has two limitations that makes 
> it impossible:

Hugh???

> 1. There cannot be nested bridge devices.

That would be a show stopper.

> 2. Each device can belong to only one bridge device.

I was aware of this second limitation.  But I don't think I was 
(directly) making a device more than one bridge.

> Eventually I have come to understanding that my problem has no fine 
> solution with no risks for performance. Partially I can solve it on 
> application layer, partially by using bridging.

*nod*

At least you now have a better understanding of what you are trying to 
solve, which is helpful when trying to solve it.

> And talking with you enlightened me on the ways of doing it.

I'm glad that I was able to help.  Even if I just held the flash light 
and you did the discovery on your own.

> Thanks for your efforts and ideas.

You are welcome.

I'm going to give another reply for an even more strange idea (extension 
of my earlier idea) that might get around your first point above.



Grant. . . .

Re: ebtables & VLAN redirect

[Grant Taylor]

On 06/30/10 16:09, Taylor, Grant wrote:
> That would be a show stopper.

... unless ...

> I'm going to give another reply for an even more strange idea (extension 
> of my earlier idea) that might get around your first point above.

I have messed with creating virtual networks in Linux for various 
different reasons.  One of the virtual networks that I was going to 
create (but the problem changed before I needed to do so) was to create 
a pair of devices connected to each other like a cross over cable using 
socat.

With this in mind, you could create a number of pairs of virtual devices 
and use them to connect the bridges together.

eth0.101 <-> br101 <-> ve101a   ve101b <-> br9
eth0.102 <-> br102 <-> ve102a   ve102b <-> br9
eth0.103 <-> br103 <-> ve103a   ve103b <-> br9 <-> eth1.9
...
eth0.199 <-> br199 <-> ve199a   ve199b <-> br9

Thus, there is no nesting and no device is in more than one bridge group.

So traffic coming in eth0.123 would be filtered by ebtables rules for 
br1234 before going in to ve123a.  Traffic would then pass through socat 
and come out ve123b and in to br9 and subsequently out eth1.9.

You might want to brief your self with how Xen does it's networking as 
it uses virtual point to point network pairs like what I'm calling 
ve<bla>a and ve<bla>b.



Grant. . . .