From: Andrew andrewd@uccsda.org
To: lartc@vger.kernel.org
Subject: [LARTC] Advanced Routing problem (Can someone PLEASE answer this!)
Date: Thu, 14 Dec 2000 21:25:36 +0000 [thread overview]
Message-ID: <marc-lartc-98373938217030@msgid-missing> (raw)
In-Reply-To: <marc-lartc-98373938217029@msgid-missing>
<PRE>Hello, see comments belo
><i> > ##############################################################################
</I>><i> > # Define routing rules
</I>><i> > ##############################################################################
</I>><i> >
</I>><i> > #rules for packets coming in eth0 (LAN)
</I>><i> > ip rule add iif eth0 to 204.x.x.0/24 lookup to-lan priority 100
</I>><i> > ip rule add iif eth0 to 172.x.x.1/32 lookup main priority 110
</I>><i>
</I>><i> 172.x.x.1/32 -- I'd say just offhand that needs to be 172.x.x.1/24. Why
</I>><i> 32?
</I>The point of the .../32 is to specify a single unique ip address. /24 would
specify
the whole subnet of 254 addresses, and I don't want that. I could just as easily
have
said "ip rule add iif eth0 to 172.x.x.1 lookup main priority 110". The ip
command
will take it either way.
If you want proof look below at the second listing with "ip rule ls", or try it
yourself.
You will see that rule 110 is listed as a unique ip address.
><i>
</I>><i> >
</I>><i> > #catch all rule
</I>><i> > ip rule add from 0.0.0.0/0 type blackhole lookup bit-bucket priority 500
</I>><i> >
</I>><i> > ##############################################################################
</I>><i> > # Create routing tables referenced by rules above
</I>><i> > # Note: the table names used below must exist in the
</I>><i> > # /etc/iproute2/rt_tables file
</I>><i> > ##############################################################################
</I>><i> >
</I>><i> > #to-lan table routes
</I>><i> > ip route add default dev eth0 table to-lan
</I>><i> >
</I>><i> > #bit-bucket table routes
</I>><i> > ip route add blackhole default table bit-bucket
</I>><i> >
</I>><i> > # Make rules/routes active
</I>><i> > ip route flush cache
</I>><i> >
</I>><i> > # Enable IP forwarding since it is disabled by default
</I>><i> > echo "1" > /proc/sys/net/ipv4/ip_forward
</I>><i> >
</I>><i> > # Enable automatic IP defragmenting since it is disabled by default
</I>><i> > echo "1" > /proc/sys/net/ipv4/ip_always_defrag
</I>><i> > #---------end script
</I>><i> >
</I>><i> > When I'm all done, an ip rule ls shows the following
</I>><i> >
</I>><i> > 0: from all lookup local
</I>><i> > 100: from all to 204.x.x.0/24 iif eth0 lookup to-lan
</I>><i> > 110: from all to 172.x.x.1 iif eth0 lookup main
</I>><i> > 500: from all lookup bit-bucket blackhole
</I>><i> > 32766: from all lookup main
</I>><i> > 32767: from all lookup default
</I>><i> >
</I>><i> > So far so good. I can now hop over to orion and begin to test. I set
</I>><i> > the default gw on orion to point to 172.x.x.1 and try to ping
</I>><i> > 204.x.x.2 (our dns server) which answers back fine. So rule 100
</I>><i> > is working and redirecting things to the cisco router on our 172
</I>><i> > network which has that particular 204 network attached to it.
</I>><i> >
</I>><i> > But when I ping 172.x.x.1, cygnus' address I get nothing. Hopping
</I>><i> > over to cygnus' terminal and running tcpdump shows me that the packets
</I>><i> > are indeed arriving but they aren't making it. As it ends up, they are
</I>><i> > getting blackholed by rule 500 above. I know this because If I delete
</I>><i> > rule 500 from the command line the ping starts getting responded to,
</I>><i> > furthermore if I delete rule 32766 after that, it quits again.
</I>><i>
</I>><i> I'd say this more or less confirms it.
</I>><i>
</I>><i> What does ip route ls show?
</I>
All ip route ls shows is my default routing table (main) the same thing
you would see if you ran say the "route -n" command after executing
"/etc/rc.d/init.d/network start"
there are also two other tables: to-lan, and bit-bucket which each have
a single default route in them as you can see from the script above.
-Andrew
</PRE>
prev parent reply other threads:[~2000-12-14 21:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-14 17:22 [LARTC] Advanced Routing problem (Can someone PLEASE answer this!) Andrew
2000-12-14 21:25 ` Andrew [this message]
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-98373938217030@msgid-missing \
--to=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.