ok so it's not like the cef switched R2 is marking them just passing them through and yes same de-list on all 3 routers
would this not mean that packets coming into an enterprise router from say a LAN switch be processed switched therefore no real need to have cef transit routers to initiate the marking, please correct me.. thanks Bob On 8 October 2012 01:55, Bob McCouch <[email protected]> wrote: > 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
