[c-nsp] How to prevent https facebook from the cisco router 1841
Scott Granados
scott at granados-llc.net
Thu Nov 14 10:53:08 EST 2013
Another +1
Open DNS is a great work around and allows for easy management in the event you wish to block further sites.
On Nov 14, 2013, at 10:40 AM, Pablo Lucena <plucena at coopergeneral.com> wrote:
> You can do something like this on a 1841:
>
> class-map match-any BLOCKED-WEBSITES
> match access-group name BLOCKED-WEBSITES-ACL
> match protocol http host "*facebook*"
>
> policy-map BLOCK_WEB
> class BLOCKED-WEBSITES
> drop
>
> int f0/0
> service-policy input BLOCK_WEB
>
> The ACL can also be used to match on specific IPs...you can do a nslookup
> on facebook.com and get the list of addresses that resolved. This can
> change though (as you know facebook has MANY addresses).
>
> Another fault with this is that it only matches on HTTP. If the user uses
> HTTPS then they can get through.
>
> A better option would be using OpenDNS (free!). You can block specific web
> pages, or entire categories of web pages. Then on your router you can set
> up filtering of outbound DNS traffic to any other DNS server besides the
> OpenDNS ones (to stop smart users that figure out that by changing their
> DNS server they can bypass the block).
>
>
> Pablo
>
> On Thu, Nov 14, 2013 at 10:02 AM, <cisco-nsp-request at puck.nether.net> wrote:
>
>> Send cisco-nsp mailing list submissions to
>> cisco-nsp at puck.nether.net
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> or, via email, send a message with subject or body 'help' to
>> cisco-nsp-request at puck.nether.net
>>
>> You can reach the person managing the list at
>> cisco-nsp-owner at puck.nether.net
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of cisco-nsp digest..."
>>
>>
>> Today's Topics:
>>
>> 1. [IOS XR] export to default-vrf (Catalin Petrescu)
>> 2. Re: [IOS XR] export to default-vrf (Oliver Boehmer (oboehmer))
>> 3. Re: 7600 10GE card recommendations (1 & 2 port cards)
>> (James Bensley)
>> 4. Re: [IOS XR] export to default-vrf (Catalin Petrescu)
>> 5. Re: Effect of simultaneous TCP sessions on bandwidth (Tom Storey)
>> 6. Re: How to prevent https facebook from the cisco router 1841
>> (A.L.M.Buxey at lboro.ac.uk)
>> 7. Re: How to prevent https facebook from the cisco router 1841
>> (Doug McIntyre)
>> 8. Re: [IOS XR] export to default-vrf (Catalin Petrescu)
>> 9. Re: nexus-switche issues no arp-requests (Oswald, Thomas)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 14 Nov 2013 10:36:45 +0200
>> From: Catalin Petrescu <cpmarvin at gmail.com>
>> To: cisco-nsp at puck.nether.net
>> Subject: [c-nsp] [IOS XR] export to default-vrf
>> Message-ID:
>> <CAP=_-
>> 9Nqqp9XVsxZw_dbFJ9UGF_b0Uxjr7Vtc9bonRu_dxRdfw at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Hi all,
>>
>> Did anyone get this to work on XR 4.3.2.
>>
>> vrf TEST
>> address-family ipv4 unicast
>> export to default-vrf route-policy default_policy_pass_all
>>
>> route-policy default_policy_pass_all
>> pass
>> end-policy
>>
>> router bgp
>>
>> vrf TEST
>> rd 1:1
>> address-family ipv4 unicast
>> redistribute connected metric 10
>> redistribute static metric 10
>>
>> RP/0/RSP1/CPU0:#sh route vrf TEST
>> ....
>> B 99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default),
>> 17:54:43
>>
>> RP/0/RSP1/CPU0:#sh route 99.99.99.1
>> Thu Nov 14 03:34:31.038 EET
>>
>> % Network not in table
>>
>> the goal is to get routers ( 99.99.99.1/32) from vrf TEST in grt (
>> defaul-vrf) .
>>
>> Thx,
>>
>> Catalin Petrescu
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 14 Nov 2013 09:07:36 +0000
>> From: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
>> To: Catalin Petrescu <cpmarvin at gmail.com>, "cisco-nsp at puck.nether.net"
>> <cisco-nsp at puck.nether.net>
>> Subject: Re: [c-nsp] [IOS XR] export to default-vrf
>> Message-ID: <CEAA5035.6F35C%oboehmer at cisco.com>
>> Content-Type: text/plain; charset="us-ascii"
>>
>>
>>> Hi all,
>>>
>>> Did anyone get this to work on XR 4.3.2.
>>>
>>> vrf TEST
>>> address-family ipv4 unicast
>>> export to default-vrf route-policy default_policy_pass_all
>>>
>>> route-policy default_policy_pass_all
>>> pass
>>> end-policy
>>>
>>> [...]
>>> RP/0/RSP1/CPU0:#sh route vrf TEST
>>> ....
>>> B 99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default),
>>> 17:54:43
>>
>> is this an iBGP or an eBGP vrf route you are trying to export? Only
>> external or locally originated routes are candidates to be exported from a
>> VRF (anywhere, wether in global or into a different VRF), you need to do
>> this on the originating PE. This rule is there to avoid loops, similar to
>> standard BGP advertisement rule of only sending iBGP paths to external or
>> RR-client peers.
>>
>> oli
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 14 Nov 2013 09:42:05 +0000
>> From: James Bensley <jwbensley at gmail.com>
>> To: Nick Hilliard <nick at foobar.org>, "cisco-nsp at puck.nether.net"
>> <cisco-nsp at puck.nether.net>
>> Subject: Re: [c-nsp] 7600 10GE card recommendations (1 & 2 port cards)
>> Message-ID:
>> <
>> CAAWx_pXWiOrGM-1TLCjgj_Zjb6UncFs2ei_BjrUQJCH+A1KKBg at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Hi Nick,
>>
>> Many thanks for the info, that is very useful :)
>>
>> I shall continue to research and include the Ws-X7604-10GE.
>>
>> Kind regards,
>> James.
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 14 Nov 2013 13:57:39 +0200
>> From: Catalin Petrescu <cpmarvin at gmail.com>
>> To: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
>> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
>> Subject: Re: [c-nsp] [IOS XR] export to default-vrf
>> Message-ID:
>> <CAP=_-
>> 9P+gCn+HZYpJ3fLaP8tuEf8e+5VvaedDGvQUQk+Ovo-UA at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> hi Oliver,
>>
>> In this case it's a iBGP route but i've tested with connected static and
>> ospf and it's the same.
>>
>> vrf RO_CASA
>> address-family ipv4 unicast
>> import route-target
>> 1:1
>> !
>> export to default-vrf route-policy default_policy_pass_all
>> export route-target
>> 1:1
>> !
>>
>> RP/0/RSP1/CPU0:#sh route vrf TEST
>> .....
>> C 10.10.100.0/24 is directly connected, 21:18:10, BVI1
>> L 10.10.100.200/32 is directly connected, 21:18:10, BVI1
>> C 10.200.200.0/24 is directly connected, 00:01:40, TenGigE0/0/1/3.200
>> L 10.200.200.1/32 is directly connected, 00:01:40, TenGigE0/0/1/3.200
>> B 99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default),
>> 21:15:11
>> L 192.168.1.1/32 is directly connected, 21:18:10, Loopback100
>> O 200.200.200.200/32 [110/2] via 10.200.200.200, 00:01:32,
>> TenGigE0/0/1/3.200
>>
>> RP/0/RSP1/CPU0:# sh route 10.10.100.0
>> Thu Nov 14 06:54:56.034 EET
>>
>> % Network not in table
>>
>> RP/0/RSP1/CPU0:#sh route 200.200.200.200
>> Thu Nov 14 06:55:02.156 EET
>>
>> % Network not in table
>>
>> Thx,
>>
>> Catalin
>>
>>
>>
>> On Thu, Nov 14, 2013 at 11:07 AM, Oliver Boehmer (oboehmer) <
>> oboehmer at cisco.com> wrote:
>>
>>>
>>>> Hi all,
>>>>
>>>> Did anyone get this to work on XR 4.3.2.
>>>>
>>>> vrf TEST
>>>> address-family ipv4 unicast
>>>> export to default-vrf route-policy default_policy_pass_all
>>>>
>>>> route-policy default_policy_pass_all
>>>> pass
>>>> end-policy
>>>>
>>>> [...]
>>>> RP/0/RSP1/CPU0:#sh route vrf TEST
>>>> ....
>>>> B 99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default),
>>>> 17:54:43
>>>
>>> is this an iBGP or an eBGP vrf route you are trying to export? Only
>>> external or locally originated routes are candidates to be exported from
>> a
>>> VRF (anywhere, wether in global or into a different VRF), you need to do
>>> this on the originating PE. This rule is there to avoid loops, similar to
>>> standard BGP advertisement rule of only sending iBGP paths to external or
>>> RR-client peers.
>>>
>>> oli
>>>
>>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Thu, 14 Nov 2013 13:08:45 +0000
>> From: Tom Storey <tom at snnap.net>
>> To: Youssef Bengelloun-Zahr <youssef at 720.fr>
>> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
>> Subject: Re: [c-nsp] Effect of simultaneous TCP sessions on bandwidth
>> Message-ID:
>> <
>> CAFDgZgUmqKSCMQjQ0w_uXUbyg4UTTV42vpdLx+uh2HC9JyLeNg at mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> So if I understand this correctly, with two tests running, each test
>> only manages about 50% of the bandwidth of the link?
>>
>> Are these tests sending data in only one direction, or both?
>>
>> If they are sending data in both directions, would it not make sense
>> that each can only use about half the link? A sends ~50% to B which is
>> repeated back to A, and C sends ~50% to D which is repeated back to C.
>> That makes about 100% utilisation each way?
>>
>> Maybe I missed something...
>>
>> On 10 November 2013 21:26, Youssef Bengelloun-Zahr <youssef at 720.fr> wrote:
>>>
>>>
>>> Le 11 nov. 2013 ? 04:22, Randy <randy_94108 at yahoo.com> a ?crit :
>>>
>>>>
>>>>
>>>>>>> - TCP traffic hits some kind of limit and isn't able to achieve
>> more
>>>>>>> than 40-60 Mbits/s in average <=== That's the problem we are
>> facing
>>>>
>>>> what happens if you do this -
>>>>
>>>>
>>>> a transfer from host A(fra) to host B(ham) and another transfer at the
>> same time from host D(ham) to host C(fra)? Do still avg at 90M for each
>> transfer or do both drop to the 40M avg? If you pull off 90M it would
>> eliminate the link. If not; since you have enabled high performance
>> options, tcp timestamping used to calculate RTT perceives congenstion(with
>> the increase of traffic across link) and initiates slowstart.
>>>
>>> Hello,
>>>
>>> Funny you mention this :
>>>
>>> a- first, we start transfer from A (FRA) to B (HAM), we achieve BW close
>> to 90 mbits/s,
>>>
>>> b- second, we start transfer from B to A (while first transfer is
>> running) and BW for first transfer collapses.
>>>
>>>
>>>>
>>>> if what you are seeing only applies for simultanours transfers:
>>>>
>>>> A To B and B to A, It would seem to imply A and B are the bottlenecks.
>>>
>>> Hello, seems very unlikely to me :
>>>
>>> - At location A, we have a Brocade CER-RT acting as a PE delivering
>> Layer 2 service to the customer.
>>>
>>> Customer server is directly connected using a GigE port.
>>>
>>> - At location B, we have some kind of Alcatel CPE provided by LL
>> provider.
>>>
>>> Customer server is directly connected using a FE port.
>>>
>>> Thanks.
>>>
>>>
>>>
>>>>
>>>> hth,
>>>> ./Randy
>>>>
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Thu, 14 Nov 2013 13:43:33 +0000
>> From: A.L.M.Buxey at lboro.ac.uk
>> To: mohamed nagy <eng.mohamednagy at gmail.com>
>> Cc: cisco-nsp at puck.nether.net
>> Subject: Re: [c-nsp] How to prevent https facebook from the cisco
>> router 1841
>> Message-ID: <20131114134333.GB9160 at lboro.ac.uk>
>> Content-Type: text/plain; charset=us-ascii
>>
>> Hi,
>>
>>> i need to prevent users to open Facebook https traffic from my router
>> cisco
>>> 1841
>>
>> you will need to invest in other technology that can achieve this...and
>> wonder
>> why you dont get the best people working for your company. blocking
>> facebook isnt
>> a technical issue...its a human resource issue. if your company doesnt
>> want users
>> accessing facebook from your network (at which point they'll use the
>> 3G/4G/etc with
>> their own devices) then they need to know this and management need to deal
>> with it.
>> ensure proper disciplinary proceedings for anyone caught doing facebook on
>> company
>> time and then the problem will be solved.....(but see my point about the
>> sort of
>> people who will work there).
>>
>> alan
>>
>>
>> ------------------------------
>>
>> Message: 7
>> Date: Thu, 14 Nov 2013 08:05:37 -0600
>> From: Doug McIntyre <merlyn at geeks.org>
>> To: cisco-nsp at puck.nether.net
>> Subject: Re: [c-nsp] How to prevent https facebook from the cisco
>> router 1841
>> Message-ID: <20131114140537.GA45235 at geeks.org>
>> Content-Type: text/plain; charset=us-ascii
>>
>> On Thu, Nov 14, 2013 at 01:43:33PM +0000, A.L.M.Buxey at lboro.ac.uk wrote:
>>>> i need to prevent users to open Facebook https traffic from my router
>> cisco
>>>> 1841
>>>
>>> you will need to invest in other technology that can achieve this...
>>
>>
>> I agree about the technology part. Run a box built to do this sort of
>> thing. I wouldn't think of using any low-end router to do firewall
>> functions any longer, dedicated hardware firewalls are a fraction of
>> the price of router hardware, and can handle infinately more bandwidth
>> and features. I could block facebook (or just about any "internet app")
>> for an internal user in about 15 seconds of setup on my FortiNet
>> firewall that my users are behind.
>>
>>> .. blocking facebook isnt a technical issue...its a human resource
>>> issue. if your company doesnt want users accessing facebook from
>>> your network (at which point they'll use the 3G/4G/etc with their
>>> own devices) ..
>>
>>
>> If they have a 1841 router, it is probably a smaller company, and they
>> probably don't have the resources to police their users like a larger
>> company. A technology solution is easier.
>>
>> But it is a whole different thing to check sites on your phone
>> bypassing work restrictions, vs. on the desktop. On the desktop, it
>> is hard for a manager to see if the user is doing legit work functions
>> or not, but always fondling their phone is totally different looking
>> to the manager.
>>
>> If you need to just train the employee not to do the improper steps,
>> and putting in technology blocks is easier than standing over them
>> school teacher style to make sure they are working the full work day.
>>
>>
>> ------------------------------
>>
>> Message: 8
>> Date: Thu, 14 Nov 2013 16:34:08 +0200
>> From: Catalin Petrescu <cpmarvin at gmail.com>
>> To: "Oliver Boehmer (oboehmer)" <oboehmer at cisco.com>
>> Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
>> Subject: Re: [c-nsp] [IOS XR] export to default-vrf
>> Message-ID:
>> <CAP=_-
>> 9N2HmXNHqruj+tDHOx4TMWUbAAmAXRZL+wsijmmJpk5Lg at mail.gmail.com>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Thx Oliver .
>>
>> router bgp xx
>> address-family ipv4 unicast << this was missing
>>
>> vrf TEST
>> address-family ipv4 unicast
>> redistribute connected metric 10
>> redistribute static metric 10
>>
>> as the leak route is know via bgp ( in default vrf) and not
>> connected/static ( as in vrf )
>>
>> Regards,
>> Catalin
>>
>>
>> On Thu, Nov 14, 2013 at 11:07 AM, Oliver Boehmer (oboehmer) <
>> oboehmer at cisco.com> wrote:
>>
>>>
>>>> Hi all,
>>>>
>>>> Did anyone get this to work on XR 4.3.2.
>>>>
>>>> vrf TEST
>>>> address-family ipv4 unicast
>>>> export to default-vrf route-policy default_policy_pass_all
>>>>
>>>> route-policy default_policy_pass_all
>>>> pass
>>>> end-policy
>>>>
>>>> [...]
>>>> RP/0/RSP1/CPU0:#sh route vrf TEST
>>>> ....
>>>> B 99.99.99.1/32 [200/10] via 11.11.11.11 (nexthop in vrf default),
>>>> 17:54:43
>>>
>>> is this an iBGP or an eBGP vrf route you are trying to export? Only
>>> external or locally originated routes are candidates to be exported from
>> a
>>> VRF (anywhere, wether in global or into a different VRF), you need to do
>>> this on the originating PE. This rule is there to avoid loops, similar to
>>> standard BGP advertisement rule of only sending iBGP paths to external or
>>> RR-client peers.
>>>
>>> oli
>>>
>>>
>>
>>
>> ------------------------------
>>
>> Message: 9
>> Date: Thu, 14 Nov 2013 16:02:38 +0100
>> From: "Oswald, Thomas" <th.oswald at telekom.de>
>> To: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
>> Subject: Re: [c-nsp] nexus-switche issues no arp-requests
>> Message-ID:
>>
>> <D9F50A0C85164A44B0202D32455750A2041FC0D547 at QEO40075.de.t-online.corp>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> fuck! The faulty behavior disappears. Just rebooting the nexus-switch. Two
>> days to view a lots of logg-messages, error discovery, tests... For what?
>> For nothing. And now I'm not absolutely sure that the fault will not raise
>> up again. That does not inspire me with confidence.
>>
>>
>>
>> ^^?-?^^
>>
>> -----Urspr?ngliche Nachricht-----
>> Von: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] Im Auftrag von
>> Oswald, Thomas
>> Gesendet: Dienstag, 12. November 2013 17:42
>> An: cisco-nsp at puck.nether.net
>> Betreff: [c-nsp] nexus-switche issues no arp-requests
>>
>> Hallo all,
>>
>> I see a very strange behavior on my two nexus switches.
>>
>> Both are Nexus 5548 with L3-daughter-cards. Both do l2 and l3-switching,
>> ACL-filtering and other things. Furthermore I have a set of servers
>> connected to both switches in a vPC-setup. All in all I do nothing special.
>>
>> After reloading the primary switch (vpc-primary, root-bridge for all vlans
>> and hsrp-active with preemption for all SVIs) the switche comes back online
>> and after getting up all links and reconverging everthing the network
>> breaks. After a lot of debugging and curses and connection tries and a few
>> additional gray hairs later I have got it to work by pinging all
>> ip-addresses from the switch that I have previously rebooted.
>>
>> Later I do some tests to find out what was going wrong. I found out that
>> if I clear the arp-cache I will get the same issue. Pinging from server A
>> in one subnet to server B in another subnet doesn't lead to success,
>> because the switch issues no arp-requests. To make it work just ping server
>> B from the switch and all works fine. The switch does arp, the arp-table is
>> updated and the pings from the server A will reach the server B.
>>
>> Any ideas?
>>
>> Regards
>> Thomas
>> ^^?-?^^
>>
>>
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> cisco-nsp mailing list
>> cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>
>> ------------------------------
>>
>> End of cisco-nsp Digest, Vol 132, Issue 44
>> ******************************************
>>
>
>
>
> --
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list