* [LARTC] Policy routing/Zebra/VLAN problem
@ 2003-03-21 11:15 Hocking James A
2003-03-21 11:51 ` Abraham van der Merwe
0 siblings, 1 reply; 2+ messages in thread
From: Hocking James A @ 2003-03-21 11:15 UTC (permalink / raw)
To: lartc
Hi,
I have an interesting (well, it is to me!) situation involving policy
routing and VLANs.
Apologies if the description is long-winded. The network is as follows:
R2 ---- B
/
/
/
---> A --- R1
\
\
\
R3 ---- C
We send packets from A to either B or C (they are the same ultimate
destination, reached via different routes), with router R1 routing packets
based on various characteristics (such as DSCP). We are interested in
ensuring that if the link from R3 to C goes down the packets that were
destined for C get re-routed via R2.
The policy routing in R1 over-rides what OSPF learns about the state of the
link between R3 and C, and so traffic is still sent from R1 to R3. Our
initial idea was to put in a second link from R1 to R3 which would be used
to send packets back to R1 when R3's link to C was down: the policy routing
in R1 is done on the ingress interface for packets from A, so R1 routes
packets from R3 destined for B/C to R2 without issue. This worked as
expected.
R1 has a limited number of physical interfaces (and we may eventually have
more links R4 - D, R5 - E, and so on), so we tried doing the same thing
using VLANs. We configured two VLANs between R1 and R3 in the hope that
should the link from R3 to C fail, traffic would be routed back to R1 down
the second VLAN and, again, from R1 to R2 and on to B. The curious result
was that packets were re-routed back down the *same* VLAN they arrived at R3
on. Taking out the second VLAN between R1 and R3 makes no difference. This
seems highly illegal in routing terms, and I'm keen to know why it is
happening.
R2 and R3 are running Linux, kernel 2.4.21-pre4, zebra 0.94, and we are
using the latest version (1.7) of vconfig for the VLANs. R1 has been either
a Linux or Cisco router, with the same results.
Any comments/explanations much appreciated. Thanks,
James
The Information contained in this E-Mail and any subsequent correspondence
is private and is intended solely for the intended recipient(s).
For those other than the recipient any disclosure, copying, distribution,
or any action taken or omitted to be taken in reliance on such information
is prohibited and may be unlawful.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [LARTC] Policy routing/Zebra/VLAN problem
2003-03-21 11:15 [LARTC] Policy routing/Zebra/VLAN problem Hocking James A
@ 2003-03-21 11:51 ` Abraham van der Merwe
0 siblings, 0 replies; 2+ messages in thread
From: Abraham van der Merwe @ 2003-03-21 11:51 UTC (permalink / raw)
To: lartc
[-- Attachment #1: Type: text/plain, Size: 3897 bytes --]
Hi Hocking!
I had this problem a few days ago (;
Create two routing tables for link B and link C. Add default gateways in
these tables for each link (and routes to your network if you use static
routing to route packets to R2/R3)
then add rules to enqueue packets destined for your network into the main
table. then add rules to enqueue packets originating from your network to
those tables.
the dynamic routes are sent to the main table (which have the lowest
priority).
so you have
ip rule add to $net_a table main pref 50
ip rule add to $net_b table main pref 60
ip rule add from $net_a table $table_a pref 70
ip rule add from $net_b table $table_b pref 80
ip route add default via $gw_a table $table_a
ip route add default via $gw_b table $table_b
(extra static routes if you don't use dynamic routing within you network)
the rest gets added by zebra/gated/whatever you use for dynamic routing.
> I have an interesting (well, it is to me!) situation involving policy
> routing and VLANs.
> Apologies if the description is long-winded. The network is as follows:
>
>
> R2 ---- B
> /
> /
> /
> ---> A --- R1
> \
> \
> \
> R3 ---- C
>
>
> We send packets from A to either B or C (they are the same ultimate
> destination, reached via different routes), with router R1 routing packets
> based on various characteristics (such as DSCP). We are interested in
> ensuring that if the link from R3 to C goes down the packets that were
> destined for C get re-routed via R2.
>
> The policy routing in R1 over-rides what OSPF learns about the state of the
> link between R3 and C, and so traffic is still sent from R1 to R3. Our
> initial idea was to put in a second link from R1 to R3 which would be used
> to send packets back to R1 when R3's link to C was down: the policy routing
> in R1 is done on the ingress interface for packets from A, so R1 routes
> packets from R3 destined for B/C to R2 without issue. This worked as
> expected.
>
> R1 has a limited number of physical interfaces (and we may eventually have
> more links R4 - D, R5 - E, and so on), so we tried doing the same thing
> using VLANs. We configured two VLANs between R1 and R3 in the hope that
> should the link from R3 to C fail, traffic would be routed back to R1 down
> the second VLAN and, again, from R1 to R2 and on to B. The curious result
> was that packets were re-routed back down the *same* VLAN they arrived at R3
> on. Taking out the second VLAN between R1 and R3 makes no difference. This
> seems highly illegal in routing terms, and I'm keen to know why it is
> happening.
>
> R2 and R3 are running Linux, kernel 2.4.21-pre4, zebra 0.94, and we are
> using the latest version (1.7) of vconfig for the VLANs. R1 has been either
> a Linux or Cisco router, with the same results.
>
> Any comments/explanations much appreciated. Thanks,
> James
>
> The Information contained in this E-Mail and any subsequent correspondence
> is private and is intended solely for the intended recipient(s).
> For those other than the recipient any disclosure, copying, distribution,
> or any action taken or omitted to be taken in reliance on such information
> is prohibited and may be unlawful.
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
--
Regards
Abraham
All kings is mostly rapscallions.
--Mark Twain
___________________________________________________
Abraham vd Merwe - Frogfoot Networks CC
9 Kinnaird Court, 33 Main Street, Newlands, 7700
Phone: +27 21 686 1674 Cell: +27 82 565 4451
Http: http://www.frogfoot.net/ Email: abz@frogfoot.net
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-03-21 11:51 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-03-21 11:15 [LARTC] Policy routing/Zebra/VLAN problem Hocking James A
2003-03-21 11:51 ` Abraham van der Merwe
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.