Hi Tony, It was me that mentioned the de-list vs. MQC behavior on the list. Remember that regardless of CEF settings on an interface, traffic to/from the CPU will be process switched. So if you're pinging from R5 and the de-list is set up on R5, those packets are being process switched.
See the documentation on the feature for confirmation: http://www.cisco.com/en/US/docs/ios-xml/ios/wan/command/wan-f1.html#GUID-6160F4F7-0B57-4EF9-9AE8-F18B4FCF8751 Specifically, it states: "Frame Relay DE group functionality is supported on process-switched packets only" When I tested, my network looked like this: R1--eth--R2--FR--R3 When pings or HTTP traffic were originated from R2 to R3, the DE bit was set. For the same traffic originated from R1 (and this CEF switched, pure transit traffic to R2) the DE list did not take effect. Regardling the ACL match, you must remember that in many places IOS uses an ACL not as a traffic filter, but as a selector. Something that matches a permit statement is selected, and something that hits a deny statement is not selected, but not filtered. This is done in QOS class maps, route-maps for things like policy-routing, etc. So in your example, the "deny" statements simply stop HTTP traffic from being selected, and as they are not permitted by the ACL and thus nor matched by the DE-list. The two HTTP statements catch traffic that might be originating from a client or a server in either direction. After all, "permit tcp any any eq 80" would only match traffic with a TCP source port of anything, and a TCP destination port of 80. In other words, traffic from client to server. To catch return traffic from server to client, you need to select traffic that has a TCP source port of 80. Hope that helps, Bob On Sun, Oct 7, 2012 at 7:28 PM, Tony Singh <[email protected]> wrote: > Hi George > > I've labbed this with a hub and spoke topology with cef enabled by default > on all frame routers and I'm getting the icmp traffic de marked ok both > inbound and outbound as it first passes from R5 DLCI 502 > R2 DLCI 205 > repackaged to DLCI 206 > R6 DLCI 602 > > I can see the ip cef interface mappings on all 3 routers, my local icmp > pings seem to use cef although no confirmation of routed via FIB (debug ip > packet) but the replies back using the source ip address of the HUB R2 > shows routed via RIB, is this expected? > > The HUB R2 in the debug just shows these ip packets being redirected as it > uses the same interface for receiving and sending the traffic. > > Thanks in advance.. > > -- > BR > > Tony > > Sent from my iPhone on 3 > > On 7 Oct 2012, at 17:13, George Leslie <[email protected]> > wrote: > > > > > Hi Tony, > > Yes I believe that is correct, but advise to lab it up. On the other > side of the frame DLCI, put a policy map on there to match on the de-bit. > > > > This is from memory and it was a long time ago, so I hope I've not > misled you!! It could also be IOS dependent. > > > > As for the access-list, a packet that is a www packet will first hit one > of the two denys and will therefore, be denied from the de-list and hence > from marking on DLCIs 205 and 206. Other TCP or UDP or ICMP or IP traffic, > will not match the first two denies, and will fall through to the permit, > so WILL get de-marked (in theory, remembering that it might not due to the > process vs. CEF switching thing). > > > > I think it needs to be labbed up to verify. > > > > G. > > Subject: Re: [OSL | CCIE_RS] V1 task 6.16 FR > > From: [email protected] > > Date: Sun, 7 Oct 2012 17:02:06 +0100 > > To: [email protected]; [email protected] > > > > Hi George > > > > Thanks for the detailed reply so traffic generated from the router will > always get marked but traffic going through (cef) the router would not? > Will lab it later... > > > > WRT defining the de-list where I say match "ip" from access list "101" > how does this ignore the "deny www" traffic would matching "ip" not > automatically match any www traffic too? Or would the "deny www" explicitly > not set the de bit for this traffic , struggling to understand this bit > (pardon pun) > > > > -- > > BR > > > > Tony > > > > Sent from my iPhone on 3 > > > > On 7 Oct 2012, at 16:22, George Leslie <[email protected]> > wrote: > > > > Hi Tony, > > I don't have the lab book in front of me, so this is from memory!! > > > > Your config will set the DE bit in the frame relay frame, for all IP > packets, other than HTTP packets, sent out DLCI 205 or 206. > > > > You need the second deny as the HTTP packets could either be heading out > towards a server, or coming back from a server. If the task does not state > where the http server is, then you need to accound for both. > > > > First deny would be outbound towards a server that lives the other side > of the frame network; second deny would mean the server is on your side of > the frame network. > > > > There is a slight gotcha with this command, that came up on this forum > last year. This command actually only works for packets that are process > switched, not CEF or fast switches. So, in the real lab, this is an "ask > the proctor moment", as disabling CEF on the interface may disable other > necessary functions. > > > > So, you'd have to ask the proctor if they are only looking for the > command in the config, or if you should be using MQC syntax to achieve the > same thing. > > > > HTH, George. > > > > > Date: Sun, 7 Oct 2012 04:06:59 +0100 > > > From: [email protected] > > > To: [email protected] > > > Subject: [OSL | CCIE_RS] V1 task 6.16 FR > > > > > > Hi > > > > > > Sorry for the dumb question but I'm struggling to understand the logic > when > > > de bit is set to on for the following traffic.... > > > > > > frame-relay de-list 1 protocol ip list 101 > > > > > > frame-relay de-group 1 205 > > > frame-relay de-group 1 206 > > > > > > access-list 101 deny tcp any any eq www > > > access-list 101 deny tcp any eq www any > > > access-list 101 permit ip any any > > > > > > i.e de bit set to on, on the frame-relay frame > we mark the ip > packets for > > > de > passed to service provider who can discard at times of congestion > > > > > > how is deny tcp www "allowed on the CIR" against this de-list using > this > > > reverse logic, how does this work technically? is it that de-list > looks for > > > only a permit statement in the referenced acl & any deny it ignores? > > > > > > and why do we use the second acl statement, is this not covered by the > > > first acl statement? > > > > > > BR > > > > > > Tony > > > _______________________________________________ > > > For more information regarding industry leading CCIE Lab training, > please visit www.ipexpert.com > > > > > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com > > > > > > http://onlinestudylist.com/mailman/listinfo/ccie_rs > _______________________________________________ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > > Are you a CCNP or CCIE and looking for a job? Check out > www.PlatinumPlacement.com > > http://onlinestudylist.com/mailman/listinfo/ccie_rs > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com http://onlinestudylist.com/mailman/listinfo/ccie_rs
