From: Jongsoo.Kim@Intelsat.com
Date: Sat Mar 19 2005 - 07:06:32 GMT-3
Sumit/Tim
I labbed this out and basically, R1 is hub and R2 and R3 is spoke.
I make R2(=172.16.123.2) is preferred but if its is down, then R3 will be
preferred.
Just make it simple, I didn't include IP prec = 3 in ACL
And I use traceroute to validate the result
Toplogy
FRS-e0=172.16.67.0/24 .6=e0-R6-ATM1/0=.6 172.16.16.0/24 .1=ATM3/0-R1
And
R1-S0/0.123=.1 172.16.123.0/24 .2 =S0/0-R2
.3 =S0/0-R3
1) Without Policy-route, it doesn't go to R2(=172.16.123.2)
because R3 is next-hop on routing table for 172.16.50.17.
FRS#traceroute 172.16.50.17
Type escape sequence to abort.
Tracing the route to 172.16.50.17
1 172.16.67.6 4 msec 4 msec 0 msec
2 172.16.16.1 32 msec 20 msec 20 msec
3 172.16.123.3 56 msec 37 msec 32 msec
4 172.16.35.5 56 msec * 52 msec
FRS#
2) With Policy-route
without "set ip next-hop verify-availability"
And without "CDP enable"
2-1) When 172.16.123.2 is reachable
R1
interface ATM3/0
ip policy route-map test
access-list 100 permit ip 172.16.67.0 0.0.0.255 any
route-map test permit 10
match ip address 100
set ip next-hop 172.16.123.2 172.16.123.3
FRS#traceroute 172.16.50.17
Type escape sequence to abort.
Tracing the route to 172.16.50.17
1 172.16.67.6 4 msec 4 msec 0 msec
2 172.16.16.1 28 msec 20 msec 20 msec
3 172.16.123.2 56 msec 36 msec 36 msec
4 172.16.123.1 36 msec 32 msec 28 msec
5 172.16.123.3 81 msec 56 msec 76 msec
6 172.16.35.5 60 msec * 72 msec
2-2) When 172.16.123.2 is not available,
FRS#traceroute 172.16.50.17
Type escape sequence to abort.
Tracing the route to 172.16.50.17
1 172.16.67.6 4 msec 4 msec 0 msec
2 172.16.16.1 81 msec 32 msec 20 msec
3 * * *
4 * * *
Basically "set ip next-hop 172.16.123.2 172.16.123.3" alone didn't work.
3) With Policy-route
with "set ip next-hop verify-availability"
And with "CDP enable" on R1, R2, R3
interface ATM3/0
ip policy route-map test
access-list 100 permit ip 172.16.67.0 0.0.0.255 any
route-map test permit 10
match ip address 100
set ip next-hop 172.16.123.2 172.16.123.3
set ip next-hop verify-availability
3-1)When 172.16.123.2 is reachable
FRS#traceroute 172.16.50.17
Type escape sequence to abort.
Tracing the route to 172.16.50.17
1 172.16.67.6 4 msec 4 msec 0 msec
2 172.16.16.1 28 msec 20 msec 20 msec
3 172.16.123.2 56 msec 36 msec 36 msec
4 172.16.123.1 36 msec 32 msec 28 msec
5 172.16.123.3 81 msec 56 msec 76 msec
6 172.16.35.5 60 msec * 72 msec
3-2)When 172.16.123.2 is unreachable
FRS#traceroute 172.16.50.17
Type escape sequence to abort.
Tracing the route to 172.16.50.17
1 172.16.67.6 0 msec 4 msec 4 msec
2 172.16.16.1 709 msec 20 msec 12 msec
3 172.16.123.3 36 msec 41 msec 160 msec
4 172.16.35.5 44 msec * 52 msec
Note with "set ip next-hop verify-availability" if CDP is not enable,
then it seems the last next-hop is chosed from " set ip next-hop next1,
next2, etc".
So Lab 3 seems the solution for this.
Regards
Jongsoo
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Friday, March 18, 2005 7:46 PM
To: 'Sumit'; Kim, Jongsoo; ccielab@groupstudy.com
Subject: RE: MQC vs Policy Routing
Sumit,
I've got to hand it to you and give you loads of credit for your
perseverance in nailing down this problem. My hat goes off to you.
Looking at your solution and reading your explanation, there's still
something I'm confused about.
You say, "and specifying two next hops in one statement". Have you ever
used a set ip next-hop where you've specified 2 next-hops?
And, can you describe an example scenario and problem where this command
syntax would solve the problem.
Also, you say you couldn't get my MQC approach to work. Really? I got it
to work - at least partially. I hope you can tell me more about what you did
and what happened.
When I did it, to test that it was working, on R-C I configured an acl to
match on ip packets with ip prec 3, I then cleared the counters, and then I
pinged R-C and R-B with ip prec set to 3.
When I pinged R-B with ip prec = 3, those packets correctly went to R-C.
What I didn't test is what happens if R-C isn't available.
Now, there's still one issue left with this solution AFAIK: All packets
sourced from vlan 1 with ip prec = 3 will be sent across the f/r cloud
whether or not they should be. Of course, when they get to R-C, since R-C
has full routing info, it will just send the packet back across the f/r
cloud to R-A. Since it's then coming in R-A's f/r interface, R-A will
process it as normal and send it where it really should go. But, in the
meantime, those packets will take 2 trips across the f/r cloud for nothing.
Without specifying every network on the other side of the f/r cloud in an
acl, how can we do the equivalent of what your idea of using the match ip
next-hop would do? Is such a thing possible?
It's too bad that match ip next-hop command doesn't work with policy
routing. I really liked that idea even though I didn't think of it myself.
Thanks Sumit for all your time and effort on this problem.
Tim
-----Original Message-----
From: Sumit [mailto:sumit.kumar@comcast.net]
Sent: Friday, March 18, 2005 6:53 PM
To: Jongsoo.Kim@Intelsat.com; ccie2be@nyc.rr.com; ccielab@groupstudy.com
Subject: Re: MQC vs Policy Routing
Tim, Kim
I finally got my hands on this, yes you both are correct my previous
theoretical solution did not work. And the reason as Tim mentioned PBR is
executed before route-table lookup so policy is rejected since there's no
match for "match ip next-hop"
Here's what actually worked
acl 103 permit vlan 1 any prec 3
route-map policy permit 10
match ip address 103
set ip next-hop 136.10.100.6
set ip next-hop verify-availability
Without "verify availability" and specifying two next hops in one statement
doesn't work as router keeps on sending packets to 136.10.100.6
And we have to assume there is only one outgoing interface so no
destination based match is possible. Also since ACl will catch only traffic
with prec 5 all other traffic will forwarded as per routing table.
I couldn't make it work with MQC.
Sumit
----- Original Message -----
From: <Jongsoo.Kim@Intelsat.com>
To: <ccie2be@nyc.rr.com>; <sumit.kumar@comcast.net>;
<ccielab@groupstudy.com>
Sent: Friday, March 18, 2005 3:25 PM
Subject: RE: MQC vs Policy Routing
> Sumit
>
> I think your solution below using "match ip next-hop 10" may not do as you
> intended, based on my research.
>
> Things bothering me is the Policy routing is applied on E0/0. And IP
packet
> arriving E0/0 is examed by this policy-routing, which is before examed by
> routing table. How can router resolve the next-hop address( forwarding
> interface) of IP packet before examed by routing table.
>
> Per CCO, this commaned "match ip next-hop 10" seems for route
advertisement
> not for real traffic.
> And this make sense to me.
>
> I think we just have to remove "match ip next-hop 10"
> Maybe RA has only E0/0 and F/R multipoint interface so that any traffic
> coming into E0/0 should go out to F/R mutlipoint?
>
>
> Regards
>
>
> Jongsoo
>
>
>
>
>
> -----Original Message-----
> From: Kim, Jongsoo
> Sent: Thursday, 17 March, 2005 8:56 PM
> To: 'ccie2be'; 'Sumit'; ccielab@groupstudy.com
> Subject: RE: MQC vs Policy Routing
>
>
> Tim
>
> After I saw Sumit's solution, now I fully understand your requirement. I
was
> a little bit confused.
> I think I saw something similar to this from ipexpert lab( toward end) and
I
> am curious to find out its solution.
>
> Regards
>
> Jongsoo
>
>
>
>
>
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Thursday, 17 March, 2005 8:08 PM
> To: 'Sumit'; 'Group Study'
> Subject: RE: MQC vs Policy Routing
>
>
> Sumit,
>
> Thanks for getting back to me. I really appreciate it.
>
> Your example shows me the piece I was missing - that "match ip next-hop
10".
>
> Damn it, there's always something.
>
> As best as you can tell, what's wrong with the MQC method?
>
> As I said, I did a little testing and it seemed to work but I didn't have
a
> chance to test every possibility.
>
> Thanks again, Tim
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Sumit
> Sent: Thursday, March 17, 2005 7:48 PM
> To: ccie2be; Group Study
> Subject: Re: MQC vs Policy Routing
>
> Tim,
>
> PBR is the best match for this solution, you will use PBR route-map as:
>
> access-list 10 permit <RB FR intreface add>
> access-list 10 permit <RC FR interface add>
>
> access-list 101 permit ip vlan1 any prec 3
>
> route-map 10 IF-IP-PREC-3-GOTO-RC
> match ip add 101
> match ip next-hop 10
> set ip next-hop (RA-RC int)
> set ip default next-hop (RA-RB int)
>
> and apply policy-route map to E0/0
>
> hth
> Sumit
>
> ----- Original Message -----
> From: "ccie2be" <ccie2be@nyc.rr.com>
> To: "Group Study" <ccielab@groupstudy.com>
> Sent: Thursday, March 17, 2005 11:54 AM
> Subject: MQC vs Policy Routing
>
>
> > Hi guys,
> >
> >
> >
> > This problem stumped me. I didn't like either of the 2 solutions that
> came
> > to mind and would like to hear your thoughts.
> >
> >
> >
> > =============================
> >
> > Figure 1
> >
> >
> >
> > / -- R-B
> >
> > | ---- e0/0 R-A -- p2m f/r other networks with
> different
> > major network addresses
> >
> > \ -- R-C
> >
> >
> >
> > ==============================
> >
> > Figure 2
> >
> >
> >
> > R-A e0/0 ---- vlan 1 ------ R-d ----- R-e
> >
> >
> >
> > ==============================
> >
> >
> >
> >
> >
> > R-A is connected to vlan 1 via it's e0/0 interface and to R-d via vlan 1
> and
> > other subnets beyond that. (Fig 2)
> >
> >
> >
> > R-A is also connected to R-B and R-C via p2m f/r and can reach other
> > networks behind R-B and R-C (Fig 1)
> >
> >
> >
> > I want R-A to forward packets that originate on vlan 1 and are heading
to
> > R-B or R-C or beyond and have an ip prec of x to take the pvc to R-C if
> it's
> > available.
> >
> >
> >
> > If the pvc or R-C is down, take the other pvc. All networks behind R-B
or
> > R-C can be reached via either pvc.
> >
> >
> >
> > I'm not sure how to config this.
> >
> >
> >
> > I thought of policy routing but this was the problem I couldn't figure
> out.
> > Suppose packets originating on vlan 1 weren't suppose to head towards
R-B
> or
> > R-C? Wouldn't they just end up going to R-C or R-B only for these
routers
> > to send them back to R-A. ? And, thus waste bandwidth?
> >
> >
> >
> > Here's the pseudo code:
> >
> >
> >
> > route-map 10 IF-IP-PREC-3-GOTO-RC
> >
> > match ip-prec-3 and source = vlan1
> >
> > set ip next-hop R-C
> >
> >
> >
> > route-map 20 IF-IP-PREC-3-GOTO-RC
> >
> >
> >
> > ***********************************************
> >
> >
> >
> > The other solution I thought of was to use MQC:
> >
> >
> >
> > Assume the dlci to R-B = dlci-B and the dlci to R-C = dlci-C.
> >
> >
> >
> > Here's the pseudo code:
> >
> >
> >
> > access-list 100 permit ip vlan1 any prec 3
> >
> >
> >
> > class-map match-all IP-PREC
> >
> > match int e0/0 <-- Is this needed?
> >
> > match ip address 100
> >
> >
> >
> > policy-map IP-PREC
> >
> > class IP-PREC
> >
> > set fr-dlci <pvc-C>
> >
> >
> >
> > int f/r p2m
> >
> > service-policy out IP-PREC
> >
> >
> >
> > *****************************************************
> >
> >
> >
> > I never used the set fr-dlci command before and so I'm not 100% sure
this
> > solution actually works but I pretty sure it does. (I put an acl on R-C
> and
> > then did some pings and saw the matching packets go up but I didn't do
any
> > other testing.)
> >
> >
> >
> > Q?
> >
> >
> >
> > Will both solutions actually work?
> >
> >
> >
> > Is the MQC solution better?
> >
> >
> >
> > Is there a better solution I didn't think of?
> >
> >
> >
> > TIA, Tim
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> ############################################################
>
> Building on 40 Years of Leadership - As a global communications leader
with 40 years of experience, Intelsat helps service providers,
> broadcasters, corporations and governments deliver information and
entertainment anywhere in the world, instantly, securely and reliably.
>
> ############################################################
> This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged
> information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and
> destroy all copies of the original message. Any views
> expressed in this message are those of the individual
> sender, except where the sender specifically states them
> to be the views of Intelsat, Ltd. and its subsidiaries.
> ############################################################
>
############################################################
Building on 40 Years of Leadership - As a global communications leader with 40 years of experience, Intelsat helps service providers,
broadcasters, corporations and governments deliver information and entertainment anywhere in the world, instantly, securely and reliably.
############################################################
This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and
destroy all copies of the original message. Any views
expressed in this message are those of the individual
sender, except where the sender specifically states them
to be the views of Intelsat, Ltd. and its subsidiaries.
############################################################
This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:48 GMT-3