From: Hocking James A <JAHOCKING@qinetiq.com>
To: lartc@vger.kernel.org
Subject: [LARTC] Policy routing/Zebra/VLAN problem
Date: Fri, 21 Mar 2003 11:15:09 +0000 [thread overview]
Message-ID: <marc-lartc-104824565609446@msgid-missing> (raw)
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/
next reply other threads:[~2003-03-21 11:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-21 11:15 Hocking James A [this message]
2003-03-21 11:51 ` [LARTC] Policy routing/Zebra/VLAN problem Abraham van der Merwe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-104824565609446@msgid-missing \
--to=jahocking@qinetiq.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.