Load-balancing in a triangle ?
Hello, Could anybody comment the following problem: -I have three Cisco routers, (POPA, POPB and CUSTOMER - exact models are not important). <---uplink_1[POPA]---2Mbps-[POPB]uplink_2> ! ! ! ! +---512k---[CUSTOMER]---512k---+ ! ---+--- customer network - A customer router (CUSTOMER) is connected symmetrically both to POPA and POPB. Each customer link is 512k, and the main purpose for two links was to have backup connection (if link between POPA and CUSTOMER goes down, traffic from POPA will go POPA->POPB->CUSTOMER, and vice versa). It works as a backup. - Currently RIPv2 is used between POPA, POPB and CUSTOMER, but it can be changed to any other protocol. PROBLEM DESCRIPTION: Currently all customer traffic that comes from uplink#1 (via POPA) will flow ONLY through link POPA->CUSTOMER, even if this link is highly loaded already. The same is true about traffic coming from uplink_2: it will use only link POPB->CUSTOMER. DESIRED GOAL: Is it possible to implement some kind of load-balancing between two customer links ? That is, even if all incoming traffic for customer network comes to POPA via uplink_1, I'd like both customer 512k-links to be loaded equally (half of the traffic must flow in a path POPA->POPB->CUSTOMER). The same should be true for traffic coming via uplink_2: it must also be balanced between two 512k links. WBR, Alex PS. It is supposed that 2Mbps link between POPA and POPB may be upgraded easily as needed, so its load should not be taken into account. ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Do fragments always match extended access-list ?
Hello everybody, I recently faced one strange problem with Ciscos. If we have extended access-list: access-list 101 permit tcp from any to any eq 80 access-list 101 deny ip from any to any how does Cisco router processes fragmented packets ? The problem is, only the first fragment with offset==0 contains required layer 4 information (like TCP port number), and all subsequent fragments do not contain required information for access-list to make a decision. In theory the only "honest" approach is to associate subsequent non-informative fragments with a first one. But it looks like normal Cisco IOS DOES NOT keep fragments information, and fragments other than first one are ALWAYS passed! I suspect this because: 1) I experienced a situation when all fragments with offset!=0 were always passed by access-list 101 (even if these fragments DID NOT match entered access-list rules). 2) fragments filtering is mentioned as unique feature in IOS firewall feature set; 3) probably keeping fragment information can be very expensive in terms of CPU and memory. So IMHO in Cisco IOS ACLs there is an implicit rule like this: access-list 101 permit ip from any to any fragments ! "fragments" is an imaginary option, Cisco doesn't understand it in fact Is it true ? Now the actual problem description (why do I have this suspiction and why it makes a problem for me!). We use policy-routing for transparent cache setup; there is an extended access-list 101 that filters HTTP traffic only, and packets that match access-list are redirected to cache server. Everything works just fine, but router redirects any fragment to the cache, not only http packets fragments - as if any fragment matches access-list 101 ! For example, fragmented ping packets (ICMP) going through the router are also redirected to cache: - Ping with packet size 500 (non-fragmented) - succeeds and goes normal way (doesn't match access-list) - Ping with packet size 2000 (fragmented) fails, because the second fragment is redirected to cache (matches access-list 101, but should NOT). - Ping with packet size 2000 (fragmented) succeeds, when policy-routing is disabled. Is there any workaround for this problem and is my explanation true? Alex PS. Additional information: IOS 12.0(7)T Cisco 3640 I can send real config and sniffer capture logs if somebody needs it. PPS. I guess now we should really care about fragmented packets. Several years ago fragments were (probably) mostly an indication of poor network design. Now with widespread use of VPN/IPsec tunnels fragmentation is unavoidable. In fact, the problem above was noticed by our customers, because their VPN tunnels stopped working ;) ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Do fragments always match extended access-list ?
Hello everybody, I recently faced one strange problem with Ciscos. If we have extended access-list: access-list 101 permit tcp from any to any eq 80 access-list 101 deny ip from any to any how does Cisco router processes fragmented packets ? The problem is, only the first fragment with offset==0 contains required layer 4 information (like TCP port number), and all subsequent fragments do not contain required information for access-list to make a decision. In theory the only "honest" approach is to associate subsequent non-informative fragments with a first one. But it looks like normal Cisco IOS DOES NOT keep fragments information, and fragments other than first one are ALWAYS passed! I suspect this because: 1) I experienced a situation when all fragments with offset!=0 were always passed by access-list 101 (even if these fragments DID NOT match entered access-list rules). 2) fragments filtering is mentioned as unique feature in IOS firewall feature set; 3) probably keeping fragment information can be very expensive in terms of CPU and memory. So IMHO in Cisco IOS ACLs there is an implicit rule like this: access-list 101 permit ip from any to any fragments ! "fragments" is an imaginary option, Cisco doesn't understand it in fact Is it true ? Now the actual problem description (why do I have this suspiction and why it makes a problem for me!). We use policy-routing for transparent cache setup; there is an extended access-list 101 that filters HTTP traffic only, and packets that match access-list are redirected to cache server. Everything works just fine, but router redirects any fragment to the cache, not only http packets fragments - as if any fragment matches access-list 101 ! For example, fragmented ping packets (ICMP) going through the router are also redirected to cache: - Ping with packet size 500 (non-fragmented) - succeeds and goes normal way (doesn't match access-list) - Ping with packet size 2000 (fragmented) fails, because the second fragment is redirected to cache (matches access-list 101, but should NOT). - Ping with packet size 2000 (fragmented) succeeds, when policy-routing is disabled. Is there any workaround for this problem and is my explanation true? Alex PS. Additional information: IOS 12.0(7)T Cisco 3640 I can send real config and sniffer capture logs if somebody needs it. PPS. I guess now we should really care about fragmented packets. Several years ago fragments were (probably) mostly an indication of poor network design. Now with widespread use of VPN/IPsec tunnels fragmentation is unavoidable. In fact, the problem above was noticed by our customers, because their VPN tunnels stopped working ;) ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Do fragments always match extended access-list ?
From: ElephantChild [mailto:[EMAIL PROTECTED]]
>> So IMHO in Cisco IOS ACLs there is an implicit rule like this:
>>
>> access-list 101 permit ip from any to any fragments
>> ! "fragments" is an imaginary option, Cisco doesn't understand it in fact
>>
>> Is it true ?
>It used to be. In late 1995, it was used in an attack by sending
>overlapping fragments with different values in the TCP header. The first
>fragment (offset 0) would pass through because it had harmless source
>and destination ports, and the other fragment would pass because its
>offset was != 0, and could overwrite (depending on how reassembly was
>implemented in the receiving host) the TCP port values in the first
>fragment.
>
>Following that, the rule was changed to always reject fragments with an
>offset != 0, if they overlap the TCP header. RFC1858 discusses that in
>some depth, and ISTR that there's a security advisory somewhere on
>http://www.cisco.com/.
Ok, but this means that normal ("non-suspicious") fragments with offset!=0
are still passed by extended access-lists, whatever you write in
access-list.
Very strange, why doesn't Cisco mention this behaviour on their web-site ?
If it is a feature, not a bug, they still have to describe it. Just because
this may have a HUGE impact on network operation, especially in case of
policy-routing (like it happened with me).
I even passed CCNP without knowing this ;) (at that time I used to think
that Cisco has fragment cache for transit traffic and makes intelligent
decisions about each and every fragment).
By the way, the best workaround in my case (to setup a transparent http
cache) was to use WCCP instead of policy routing. In fact, WCCP does exactly
the same thing - reroutes all TCP packets with dst_port==80 to a cache
server. But WCCP does not have this bug - it does not reroute non-HTTP
fragments to a cache.
RGH. A terrible thought: but what WCCP does with fragmented HTTP
requests ? Will these fragmented requests reach cache server ? Didn't they
change "permit all non-suspicious fragments" to "deny all fragments"
Should verify it
Alex,
CCNP
___
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Do fragments always match extended access-list ?
> Alex, > If you are using a Cache engine (Cisco cache engine) > Go to the interface that is connected to the Internet and > redirect all http traffic to the interface where your cache > engine resides. Yes, I have already done this (I use Squid, but Squid 2.3 supports Cisco WCCP v.1). As soon as I switched to WCCP from policy-routing, the bug disappeared - no fragments leak any more. But I am trying to understand what is the problem with policy-routing. Once I may need to use it for some other applications. > Have you called TAC? Not yet, because we have found workaround with WCCP. However, somebody already called: (from http://www.squid-cache.org/Doc/FAQ/FAQ-17.html#ss17.3): == Bruce Morgan ([EMAIL PROTECTED]) notes that there is a Cisco bug relating to transparent proxying using IP policy route maps, that causes NFS and other applications to break. Apparently there are two bug reports raised in Cisco, but they are not available for public dissemination. The problem occurs with o/s packets with more than 1472 data bytes. If you try to ping a host with more than 1472 data bytes across a Cisco interface with the access-lists and ip policy route map, the icmp request will fail. The packet will be fragmented, and the first fragment is checked against the access-list and rejected - it goes the "normal path" as it is an icmp packet - however when the second fragment is checked against the access-list it is accepted (it isn't regarded as an icmp packet), and goes to the action determined by the policy route map! == Alex, CCNP ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Do fragments always match extended access-list ?
As the final conclusion in this thread: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120cavs/120m cavs.htm Caveats for Cisco IOS 12.0 IP Routing Protocols CSCdm44976: IP access lists always permit IP fragments. There is no workaround. I was told that it is fixed since 12.0(11), 12.1(2). So beware of this bug in earlier IOS versions, especially when using policy-routing. Alex CCNP ___ UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html FAQ, list archives, and subscription info: http://www.groupstudy.com Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
