Hi Pablo, The first option won't work for the HTTPs. Correct me if i'm wrong :)
I had tried for the second option before some months ago but I couldn't accomplish it by blocking the IP found by nslookup since there are lots of addresses for the site like Facebook & its not scalable as well. If you have any additional information which I could be missing here, please share that with us. Thanks & regards, Hari Sapkota CCIE#38346 On Thu, Nov 14, 2013 at 9:25 PM, Pablo Lucena <[email protected]>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, <[email protected]> > wrote: > > > Send cisco-nsp mailing list submissions to > > [email protected] > > > > 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 > > [email protected] > > > > You can reach the person managing the list at > > [email protected] > > > > 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 > > ([email protected]) > > 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 <[email protected]> > > To: [email protected] > > Subject: [c-nsp] [IOS XR] export to default-vrf > > Message-ID: > > <CAP=_- > > [email protected]> > > 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)" <[email protected]> > > To: Catalin Petrescu <[email protected]>, "[email protected]" > > <[email protected]> > > Subject: Re: [c-nsp] [IOS XR] export to default-vrf > > Message-ID: <ceaa5035.6f35c%[email protected]> > > 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 <[email protected]> > > To: Nick Hilliard <[email protected]>, "[email protected]" > > <[email protected]> > > Subject: Re: [c-nsp] 7600 10GE card recommendations (1 & 2 port cards) > > Message-ID: > > < > > caawx_pxwiorgm-1tlcjgj_zjb6uncfs2ei_bjruqjch+a1k...@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 <[email protected]> > > To: "Oliver Boehmer (oboehmer)" <[email protected]> > > Cc: "[email protected]" <[email protected]> > > Subject: Re: [c-nsp] [IOS XR] export to default-vrf > > Message-ID: > > <CAP=_- > > [email protected]> > > 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) < > > [email protected]> 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 <[email protected]> > > To: Youssef Bengelloun-Zahr <[email protected]> > > Cc: "[email protected]" <[email protected]> > > Subject: Re: [c-nsp] Effect of simultaneous TCP sessions on bandwidth > > Message-ID: > > < > > cafdgzgumqkscmqjq0w_uxubyg4uttv42vpdlx+uh2hc9jyl...@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 <[email protected]> > wrote: > > > > > > > > > Le 11 nov. 2013 ? 04:22, Randy <[email protected]> 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 [email protected] > > > 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: [email protected] > > To: mohamed nagy <[email protected]> > > Cc: [email protected] > > Subject: Re: [c-nsp] How to prevent https facebook from the cisco > > router 1841 > > Message-ID: <[email protected]> > > 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 <[email protected]> > > To: [email protected] > > Subject: Re: [c-nsp] How to prevent https facebook from the cisco > > router 1841 > > Message-ID: <[email protected]> > > Content-Type: text/plain; charset=us-ascii > > > > On Thu, Nov 14, 2013 at 01:43:33PM +0000, [email protected] 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 <[email protected]> > > To: "Oliver Boehmer (oboehmer)" <[email protected]> > > Cc: "[email protected]" <[email protected]> > > Subject: Re: [c-nsp] [IOS XR] export to default-vrf > > Message-ID: > > <CAP=_- > > [email protected]> > > 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) < > > [email protected]> 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" <[email protected]> > > To: "[email protected]" <[email protected]> > > Subject: Re: [c-nsp] nexus-switche issues no arp-requests > > Message-ID: > > > > <d9f50a0c85164a44b0202d32455750a2041fc0d...@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:[email protected]] Im Auftrag von > > Oswald, Thomas > > Gesendet: Dienstag, 12. November 2013 17:42 > > An: [email protected] > > 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 [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > cisco-nsp mailing list > > [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > > > ------------------------------ > > > > End of cisco-nsp Digest, Vol 132, Issue 44 > > ****************************************** > > > > > > -- > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
