Discussion:
[j-nsp] policy based routing, rib-groups and issues...
Bill Petrisko
2004-10-26 08:45:35 UTC
Permalink
Ok... I have been playing with this for a bit, and I think
that everything looks good. Unfortunately, it does not work.

When I apply the firewall filter to the interface we want
to policy route from, NO traffic will pass through that
interface.

I'm hoping that there is a simple explanation that I am
overlooking at this late hour....


Here is the goal:

I have a router that has multiple upstreams and peers.
We currently have a peering session to peer X over the
public peering switch.

I need to be able to bring up a NEW private session to this
peer X, and ONLY send him the traffic from a group of
servers on interface ge-7/0/0.1. All other peer X traffic
should continue to use the public session.

Also note that any traffic from these servers NOT destined
for peer X need to follow the normal inet.0 routing table.

Here is the config from the lab:

interfaces {
ge-7/0/0 {
vlan-tagging;
unit 1 {
vlan-id 1;
family inet {
filter {
input servers-to-peerX;
}
address 192.168.91.17/30;
}
}
}

routing-options {
interface-routes {
rib-group inet peerX-group;
}
rib-groups {
peerX-group {
import-rib [ inet.0 peerX.inet.0 ];
import-policy set-peer-private-comm;
}
}
route-record;
}

protocols {
bgp {
advertise-inactive;
group PEER {
neighbor 192.168.91.22 {
description "TEST public peer";
import set-peer-public-comm;
family inet {
unicast;
}
export reject-all;
peer-as 23059;
}
neighbor 192.168.91.26 {
description "TEST private peer";
import set-peer-public-comm-backup;
family inet {
unicast {
rib-group peerX-group;
}
any;
}
peer-as 23059;
}
}
}
}

policy-options {
policy-statement set-peer-private-comm {
from inactive: rib peerX.inet.0;
then {
local-preference 400;
accept;
}
}
policy-statement set-peer-public-comm {
then {
local-preference 300;
}
}
policy-statement set-peer-public-comm-backup {
then {
local-preference 290;
}
}
}

firewall {
filter servers-to-peerX {
term private-only {
then routing-instance peerX.inet.0;
}
term all-other {
then accept;
}
}
}

routing-instances {
peerX {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
}
}
}


Everything looks like it should be working:

192.168.90.0/24 is the route being received from the peer.


***@jr3.phx3-LABROUTER> show route summary
Router ID: 192.168.91.2

inet.0: 146255 destinations, 146256 routes (146218 active, 36 holddown, 1 hidden)
Direct: 5 routes, 4 active
Local: 4 routes, 4 active
BGP: 146246 routes, 146209 active
Static: 1 routes, 1 active

peerX.inet.0: 11 destinations, 11 routes (10 active, 0 holddown, 1 hidden)
Direct: 5 routes, 4 active
Local: 4 routes, 4 active
BGP: 1 routes, 1 active
Static: 1 routes, 1 active


All the interface IP's and the BGP IP's from the .26 session
are properly installed in the routing table peerX:

***@jr3.phx3-LABROUTER> show route table peerX

peerX.inet.0: 11 destinations, 11 routes (10 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[Static/5] 00:31:23
to table inet.0
192.168.90.0/24 *[BGP/170] 00:15:03, MED 0, localpref 400
AS path: 23059 I
to 192.168.91.26 via ge-7/0/0.3
192.168.91.16/30 *[Direct/0/-401] 00:16:50
via ge-7/0/0.1
192.168.91.17/32 *[Local/0/-401] 00:16:49
Local via ge-7/0/0.1
192.168.91.20/30 *[Direct/0/-401] 00:16:50
via ge-7/0/0.2
192.168.91.21/32 *[Local/0/-401] 00:16:49
Local via ge-7/0/0.2
192.168.91.24/30 *[Direct/0/-401] 00:16:50
via ge-7/0/0.3
192.168.91.25/32 *[Local/0/-401] 00:16:49
Local via ge-7/0/0.3

Tracerouting to the route in the peerX.inet.0, forcing the use
of that routing instance fails:

***@jr3.phx3-LABROUTER> traceroute 192.168.90.99 routing-instance peerX
traceroute to 192.168.90.99 (192.168.90.99), 30 hops max, 40 byte packets
1 * * *
2 * * *

Tracerouting to the route via the normal routing table follows
the inet.0 route like it should:

***@jr3.phx3-LABROUTER> traceroute 192.168.90.99
traceroute to 192.168.90.99 (192.168.90.99), 30 hops max, 40 byte packets
1 192.168.91.22 1.871 ms


Even from the "server", I cannot get anywhere, on ANY route:

server-2600>traceroute 192.168.90.99

Type escape sequence to abort.
Tracing the route to 192.168.90.99

1 * * *
2 * * *


server-2600>traceroute 206.165.222.1

Type escape sequence to abort.
Tracing the route to 206.165.222.1

1 * * *
2 * * *




Yet, if I remove the interface filter that directs it to the
alternate routing group, all traceroutes work (non-peer go via
other upstreams, 192.168.90.99 peer route goes via public
peering session .22):

server-2600>traceroute 192.168.90.99
Tracing the route to (192.168.90.99)
1 (192.168.91.17) 0 msec 4 msec 0 msec
2 (192.168.91.22) 4 msec * 0 msec

server-2600>traceroute 206.165.222.1
Tracing the route to (206.165.222.1)
1 (192.168.91.17) 0 msec 0 msec 0 msec
2 (192.168.91.1) 0 msec 0 msec 24 msec
3 (64.211.60.165) 20 msec 20 msec 20 msec
4 (67.17.71.97) 64 msec 64 msec 64 msec
...etc


Hope this isn't too long winded, and isn't too confusing.

Thanks to anyone who can provide insight...

bill
Limelight Networks
Daniel Roesen
2004-10-26 08:56:55 UTC
Permalink
Post by Bill Petrisko
routing-instances {
peerX {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
}
}
}
I haven't played with this yet, but this looks fishy. What do you
want to achieve with "next-table inet.0"?

Try replacing "next-table inet.0" with "next-hop 192.168.91.26" to
send traffic down the private peering.


Best regards,
Daniel
--
CLUE-RIPE -- Jabber: ***@cluenet.de -- ***@IRCnet -- PGP: 0xA85C8AA0
Bill Petrisko
2004-10-26 09:14:48 UTC
Permalink
Post by Daniel Roesen
Post by Bill Petrisko
routing-instances {
peerX {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
}
}
}
I haven't played with this yet, but this looks fishy. What do you
want to achieve with "next-table inet.0"?
Try replacing "next-table inet.0" with "next-hop 192.168.91.26" to
send traffic down the private peering.
Does not make any difference.

The next-table inet.0 puts the following into the peerX.inet.0
table:

0.0.0.0/0 *[Static/5] 00:03:39
to table inet.0

Which, I believed might direct the traffic over to inet.0
for any routes that were not specifically in peerX.inet.0

bill
Eric Van Tol
2004-10-26 13:14:43 UTC
Permalink
I believe that if you are using VLANs, you need to use the
'interface-group' commands. Here is an example of what we have running:

probes {
term 0-log_all {
then {
count all_packets;
next term;
}
}
term as7018 {
from {
interface-group 1;
}
then {
routing-instance as7018;
}
}
term implicit-allow {
then accept;
}
interface {
fe-0/0/2 {
unit 1 {
family inet {
filter {
input probes;
group 1;
}
}
}
}
}
-----Original Message-----
From: juniper-nsp-***@puck.nether.net
[mailto:juniper-nsp-***@puck.nether.net] On Behalf Of Bill Petrisko
Sent: Tuesday, October 26, 2004 4:15 AM
To: juniper-***@puck.nether.net
Subject: Re: [j-nsp] policy based routing, rib-groups and issues...
Post by Daniel Roesen
Post by Bill Petrisko
routing-instances {
peerX {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
}
}
}
I haven't played with this yet, but this looks fishy. What do you
want to achieve with "next-table inet.0"?
Try replacing "next-table inet.0" with "next-hop 192.168.91.26" to
send traffic down the private peering.
Does not make any difference.

The next-table inet.0 puts the following into the peerX.inet.0
table:

0.0.0.0/0 *[Static/5] 00:03:39
to table inet.0

Which, I believed might direct the traffic over to inet.0
for any routes that were not specifically in peerX.inet.0

bill

_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp
Andrew Ramsey
2004-10-26 13:17:07 UTC
Permalink
Hi,

Couple of things:

1. Put a counter on the filter "servers-to-peerX" to check for packets
coming in.
2. Put a filter and counter on the interface to "peerX" (in/out) to
check for packets leaving/into the router

The static route "route 0.0.0.0/0 next-table inet.0" looks like it's
defeating the purpose of what you're trying to achieve. You should
remove it - I don't think it's causing you a problem though since you
have this:

192.168.90.0/24 *[BGP/170] 00:15:03, MED 0, localpref 400
AS path: 23059 I
to 192.168.91.26 via ge-7/0/0.3
I think it looks like you're in good shape in the "server" to "peerX"
direction. What about the other way? Is there a route for the "server"
in peerX.inet.0?

Andy
-----Original Message-----
Bill Petrisko
Sent: Tuesday, October 26, 2004 4:15 AM
Subject: Re: [j-nsp] policy based routing, rib-groups and issues...
Post by Daniel Roesen
Post by Bill Petrisko
routing-instances {
peerX {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
}
}
}
I haven't played with this yet, but this looks fishy. What
do you want
Post by Daniel Roesen
to achieve with "next-table inet.0"?
Try replacing "next-table inet.0" with "next-hop 192.168.91.26" to
send traffic down the private peering.
Does not make any difference.
The next-table inet.0 puts the following into the peerX.inet.0
0.0.0.0/0 *[Static/5] 00:03:39
to table inet.0
Which, I believed might direct the traffic over to inet.0
for any routes that were not specifically in peerX.inet.0
bill
_______________________________________________
http://puck.nether.net/mailman/listinfo/junipe> r-nsp
Bill Petrisko
2004-10-26 20:16:34 UTC
Permalink
Post by Andrew Ramsey
1. Put a counter on the filter "servers-to-peerX" to check for packets
coming in.
Added term to count at the top of the policy, and all packets from
the interface ge7/0/1.1 appear to be counted, no matter what the
destination.

Added line to count in the same term (private-only) before sending
to routing instance peerX.inet.0. These packets get counted as
well.
Post by Andrew Ramsey
2. Put a filter and counter on the interface to "peerX" (in/out) to
check for packets leaving/into the router
Packets from the server never reach the peer interface.

Packets directly pinged from the router itself do reach the .26
peer interface. (Using default inet.0 routing table.)
Post by Andrew Ramsey
The static route "route 0.0.0.0/0 next-table inet.0" looks like it's
defeating the purpose of what you're trying to achieve. You should
remove it - I don't think it's causing you a problem though since you
192.168.90.0/24 *[BGP/170] 00:15:03, MED 0, localpref 400
AS path: 23059 I
to 192.168.91.26 via ge-7/0/0.3
Removing the static route 0.0.0.0/0 has no effect on the issue.
I will leave it removed for now.
Post by Andrew Ramsey
I think it looks like you're in good shape in the "server" to "peerX"
direction. What about the other way? Is there a route for the "server"
in peerX.inet.0?
Yep, "server" is one half of a /30 that is an interface route,
all interface routes are imported into peerX.inet.0 (as shown
by a 'show route table peerX'.)

The odd part is that it seems that the router itself has no idea
how to route using this rib. Even a manual traceroute or ping
using 'routing-instance' to use the direct rib do not work:

***@jr3.phx3-LABROUTER> ping 192.168.91.26 source 192.168.91.25 routing-instance peerX
--- 192.168.91.26 ping statistics ---
8 packets transmitted, 0 packets received, 100% packet loss

(And firewall filter counter does not increase either.)

Is is almost like everything directed to this rib goes into a
black hole....

Possibly juniper bug? We are on an old release of code (5.6R2.4)
on this lab router.

Thanks for the help
bill
Andrew Ramsey
2004-10-27 15:22:35 UTC
Permalink
Hi Bill,

In your config:

firewall {
filter servers-to-peerX {
term private-only {
then routing-instance peerX.inet.0; <======here
}
term all-other {
then accept;
}
}
}

Can you change the "then routing-instance peerX.inet.0" to "then
routing-instance peerX"

Andy
Post by Eric Van Tol
-----Original Message-----
Sent: Tuesday, October 26, 2004 3:16 PM
To: Andrew Ramsey
Subject: Re: [j-nsp] policy based routing, rib-groups and issues...
Post by Andrew Ramsey
1. Put a counter on the filter "servers-to-peerX" to check for
packets coming in.
Added term to count at the top of the policy, and all packets from
the interface ge7/0/1.1 appear to be counted, no matter what
the destination.
Added line to count in the same term (private-only) before
sending to routing instance peerX.inet.0. These packets get
counted as
well.
Post by Andrew Ramsey
2. Put a filter and counter on the interface to "peerX"
(in/out) to
Post by Andrew Ramsey
check for packets leaving/into the router
Packets from the server never reach the peer interface.
Packets directly pinged from the router itself do reach the
.26 peer interface. (Using default inet.0 routing table.)
Post by Andrew Ramsey
The static route "route 0.0.0.0/0 next-table inet.0" looks
like it's
Post by Andrew Ramsey
defeating the purpose of what you're trying to achieve. You should
remove it - I don't think it's causing you a problem though
since you
Post by Andrew Ramsey
192.168.90.0/24 *[BGP/170] 00:15:03, MED 0, localpref 400
AS path: 23059 I
to 192.168.91.26 via ge-7/0/0.3
Removing the static route 0.0.0.0/0 has no effect on the
issue. I will leave it removed for now.
Post by Andrew Ramsey
I think it looks like you're in good shape in the "server"
to "peerX"
Post by Andrew Ramsey
direction. What about the other way? Is there a route for the
"server" in peerX.inet.0?
Yep, "server" is one half of a /30 that is an interface
route, all interface routes are imported into peerX.inet.0
(as shown by a 'show route table peerX'.)
The odd part is that it seems that the router itself has no
idea how to route using this rib. Even a manual traceroute
192.168.91.25 routing-instance peerX
--- 192.168.91.26 ping statistics ---
8 packets transmitted, 0 packets received, 100% packet loss
(And firewall filter counter does not increase either.)
Is is almost like everything directed to this rib goes into a
black hole....
Possibly juniper bug? We are on an old release of code
(5.6R2.4) on this lab router.
Thanks for the help
bill
Daniel Roesen
2004-10-27 15:30:06 UTC
Permalink
Post by Bill Petrisko
firewall {
filter servers-to-peerX {
term private-only {
then routing-instance peerX.inet.0; <======here
}
term all-other {
then accept;
}
}
}
Can you change the "then routing-instance peerX.inet.0" to "then
routing-instance peerX"
Ugh... looks like a parser bug then... parser should definately
check for instance config when committing... :-Z

Good catch. :-)


Best regards,
Daniel
--
CLUE-RIPE -- Jabber: ***@cluenet.de -- ***@IRCnet -- PGP: 0xA85C8AA0
Bill Petrisko
2004-10-27 15:49:30 UTC
Permalink
Post by Bill Petrisko
firewall {
filter servers-to-peerX {
term private-only {
then routing-instance peerX.inet.0; <======here
}
term all-other {
then accept;
}
}
}
Can you change the "then routing-instance peerX.inet.0" to "then
routing-instance peerX"
Yes, that appears to have fixed the issue.
Thanks for the keen eye!

I have been tearing my hair out over this one, as this was
my first rib/routing-instance attempt.....

Also note that my trick you were wondering about below (or was that
someone else?)--

routing-instances {
peerX {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
}
}
}

Does have the desired effect I was looking for. This installs
a route in peerX.inet.0, pointing default route to inet.0.

Meaning, once no routes are matched in peerX.inet.0, it dumps
the packet back into inet for "normal" forwarding. Neat trick
for forcing users to a subset of routes, and then back into inet.0
if none match:

***@jr3.phx3-LABROUTER> show route table peerX

peerX.inet.0: 11 destinations, 11 routes (10 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[Static/5] 00:05:11
to table inet.0
192.168.90.0/24 *[BGP/170] 00:05:03, MED 0, localpref 400
AS path: 23059 I
Post by Bill Petrisko
to 192.168.91.26 via ge-7/0/0.3
thanks again for the help!

bill
Daniel Roesen
2004-10-27 15:55:25 UTC
Permalink
Post by Bill Petrisko
Also note that my trick you were wondering about below (or was that
someone else?)--
I was wondering as I didn't see any more specifics aside the 0/0
match... so this looked like a perfect loop. :-)


Best regards,
Daniel
--
CLUE-RIPE -- Jabber: ***@cluenet.de -- ***@IRCnet -- PGP: 0xA85C8AA0
Loading...