From: Jongsoo.Kim@Intelsat.com
Date: Fri Mar 18 2005 - 20:55:14 GMT-3
Sumit
Thank you very much for labbing this out.
I think I fully understand your condition and solution, which is pretty
cool!
Jongsoo
-----Original Message-----
From: Sumit [mailto:sumit.kumar@comcast.net]
Sent: Friday, 18 March, 2005 6:53 PM
To: Kim, Jongsoo; 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:47 GMT-3