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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxx
Attachment:
pgp00117.pgp
Description: PGP signature
