From: Sumit (sumit.kumar@comcast.net)
Date: Sat Jan 01 2000 - 11:34:32 GMT-3
Kim,
Thanks for adding another flavor to the solution. Looks like we have beaten
this monster to death. :)
Yes- CDP is required for "set ip next hop verify-availability", in my lab I
also reduced the cdp holdtime on the routers for faster convergence.
Tim,
I couldn't find way to make this work with MQC so if you have a config I can
verify it.
And I couldn't think of way for additional match criteria to narrow down the
scope of source traffic. (one option is to do something on FR interface)
During this course I came across an interesting command " ip policy-list
recommended for BGP - seemed helpful.
This was a good brain teaser-- keep em coming.
Sumit
----- Original Message -----
From: "ccie2be" <ccie2be@nyc.rr.com>
To: "'Sumit'" <sumit.kumar@comcast.net>; <Jongsoo.Kim@Intelsat.com>;
<ccielab@groupstudy.com>
Sent: Friday, March 18, 2005 7:45 PM
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
> > >
> > >
This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:48 GMT-3