The counters show the number of frames that have been seen with the marking, not just the number marked by the local router.
Do you have the same de-list on both R5 and R6? Bob -- Sent from my iPhone, please excuse any typos. On Oct 7, 2012, at 8:45 PM, Tony Singh <[email protected]> wrote: Hi Bob Thanks for the awesome reply really appreciate it. here's what I see, if R2 is purely transit (HUB & cef switched) should I be seeing the de packets incrementing on R2? or is it a case that the marking has already been done by R5 and R2 is simply incrementing the counters? *Ping from R5 to R6 via R2 HUB* *R5#ping 150.100.100.6* Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 150.100.100.6, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 112/114/124 ms R5#ping 150.100.100.6 Prior to ping *R5#show frame-relay pvc 502* in DE pkts 59 out DE pkts 79 Post in DE pkts 60 out DE pkts 84 Prior to ping *R2#show frame-relay pvc 205* in DE pkts 79 out DE pkts 59 Post in DE pkts 84 out DE pkts 60 Prior to ping *R2#show frame-relay pvc 206* in DE pkts 63 out DE pkts 23 Post in DE pkts 68 out DE pkts 24 Prior to ping *R6#show frame-relay pvc 602* in DE pkts 23 out DE pkts 63 Post in DE pkts 24 out DE pkts 68 Thanks in advance Tony On 8 October 2012 01:10, Bob McCouch <[email protected]> wrote: > 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
