From: Phillip Arthur (pvarthur@hotmail.com)
Date: Mon Dec 10 2007 - 16:44:30 ART
The problem with your solution is the lab requests that you mark traffic
incoming on the ethernet interface. If by chance you had another serial
connection that traffic could arrive on, that traffic to would get marked DE
when it exited the Frame Relay connection and not meet the requirements of the
question.On a side note, we follow the same methodology that you proposed with
your solution on our WAN circuits with a large service provider. We classify,
mark, and queue on egress to the WAN cloud. Since I am classifying I can
queue according to what I want, and by marking the traffic as well, the
service provider is able to queue based on my preferences within their core
and our contracted guarantees. This might not meet Cisco's design guidelines,
however, it meets my administrative requirements since I historically have not
had management control of the access layer at our sites.
> Date: Mon, 10 Dec 2007 22:23:53 +0400> From: joseph.samir.saad@gmail.com>
To: JBiggs@usaid.gov> Subject: Re: IPEXPERT LAB 24> CC:
ccielab@groupstudy.com> > I thought marking is always done inbound on an
interface and the Service> policy is applied outbound on S0/0. It breaks my
head that this would be> working actually.> > Any thoughts?> > On Dec 10, 2007
7:10 PM, Biggs, Jeff (M/CIO/BIE) <JBiggs@usaid.gov> wrote:> > > The lab tells
you to mark all traffic incoming on the Ethernet FR-DE> > interface of R2. The
solution provided is to use a Frame-relay DE list,> > but couldn't you do
this:> >> >> >> > class-map match-all DE> >> > match access-group 12> >> > !>
>> > !> >> > policy-map DE> >> > class DE> >> > set fr-de> >> > !> >> >
interface Serial0/0> >> > ip address 150.50.10.2 255.255.255.0> >> >
encapsulation frame-relay> >> > ip ospf priority 100> >> > no arp frame-relay>
>> > frame-relay map ip 150.50.10.2 204> >> > frame-relay map ip 150.50.10.4
204 broadcast> >> > frame-relay map ip 150.50.10.5 205 broadcast> >> >
frame-relay map ip 150.50.10.6 206 broadcast> >> > no frame-relay inverse-arp>
>> > service-policy output DE> >> >> >> >> >> > access-list 12 permit
150.50.12.0 0.0.0.255> >> >> >> > Jeffrey Biggs> >> > Sr. Network Engineer> >>
> USAID> >> > M/CIO/BIE> >> > 240-646-5003> >> > jbiggs@usaid.gov
<mailto:jbiggs@usaid.gov>> >> >
This archive was generated by hypermail 2.1.4 : Tue Jan 01 2008 - 12:04:30 ARST