Recent Posts

Pages: [1] 2 3 ... 10
1
Forum Lobby / Re: Football is back again
« Last post by deanwebb on Today at 07:01:44 PM »
Another bad week of pics for the early games, Dean also.
Hope I do better for the late games.

did even worse on the late games :(

So did Carson Wentz... that's so Philly for ya. Clinches division title, closer to home field advantage through the NFC playoffs... and it may all mean nothing if they're depending upon Foles to be the QB that beats Brady (or Roethlisberger) in the Super Bowl... after surviving through all the playoffs...
2
Routing and Switching / Re: ISR 4K NBAR
« Last post by wintermute000 on Today at 05:09:57 PM »
1.) You'd typically employ NBAR ingress on the LAN side and mark there. You wouldn't employ NBAR on egress. Traffic incoming should already be marked EGRESS from WAN sites and preserved by carrier QoS schema.

2.) Typically you'd QoS on physical and the schema would be inherited for all sub-interfaces. Alternatively you COULD put the service policy on sub-interfaces. I'm unsure of the BW behaviour in this case.

3.) Your QoS config looks wrong at first glance - where is the parent and child structure? Without that how is the bandwidth statements going to do anything? Typically you'd shape on the parent interface to 99% of the 'real' circuit speed (as your circuit speed is typically not hte actual interface speed). Then apply the child policy to th default class, and within the child policy you do the per-class per-BW behaviour.
3
This is a routing question. Need to understand your topology and routing design.

Do you want users at remote sites to hairpin through the central site for internet?
If yes then you need to fix your routing. Esp the default route. Typically to avoid default route clashing you'd use a front VRF design.
If no then as Dean says you need to fix your branch routing so the branches use their local internet and not the tunnel for 0.0.0.0.
THe branch FW would then use a specific route to reach the tunnel endpoints but leave the default route out the normal internet.
4
Forum Lobby / Re: Football is back again
« Last post by ristau5741 on Today at 03:18:26 PM »
Another bad week of pics for the early games, Dean also.
Hope I do better for the late games.

did even worse on the late games :(
5
I was way over looking the idea of using just PEAP. Which does make the most sense (deployed a test this morning). Kind of funny actually because I deployed this like 2 years ago for a different corp, and I didn't even think of it. My mind has been fixed on .1x as of late.


yeah I do not care about EAP-TLS, as this is just for internet. I am not going through the hassle. Even if I did attempt to create a sandbox splash page to allow users to install then proceed to connection. It is just not worth my time.

Currently we are using web-auth and it works like garbage on anything non mobile (and honestly... it sucks for mobile too).

Not to mention... I would be hard-pressed to ever go with ISE in the future. Left a very bad taste in my mouth after we spent hundreds of thousands and the AAA was not working (in a previous thread on this forum). That coupled with 4.5 hour upgrades = no go for me (as well as other monotonous things)

Now for the "But seriously, folks..." response. :)

If the wireless is for Internet-only, then you're talking about a guest network, plain and simple. BYOD devices can connect to it and then use the Internet access to VPN on in, if they need to. Pretty simple to put together, but you have to do a lot of complicated stuff before it's simple... let me explain...

Getting dot1x put together can be a trick and a half, but can be done. In the meantime, the guest network can be set up to admit everyone and put them on a MAR, so they don't have to authenticate with normal dot1x means. However, the devices also have a pre-connect ACL that only allows communications pretty much to the RADIUS server and a server (could be the same as the RADIUS server, if that box is also running a web server) that will have the registration page set up on it. User registers, submits form, and then is granted access. It could be from another employee approving it, or it can be self-approval with either a text or email sent to the device via the LTE network - or to an employee's device able to access that email account - that contains the password for the user.

Once the user submits an approved username/password, then the RADIUS server can send a Change of Authority (CoA) to the WLC that switches the device from the corporate wireless with an ACL to an SSID run by the foreign WLC in the DMZ and the device is guestin' away.

As an alternative, devices first connecting to the guest SSID face a DNS hijack for everything except "phone home" traffic to Google, Apple, and Microsoft, and the CA for the cert on the web server that all HTTP/HTTPS traffic gets pointed to... where, whaddya know, there's a web portal! Registered devices are then no longer subjected to the DNS hijack and are then allowed to actually go to web sites and stuff with all the other cool kids.

Of the two methods, I prefer the CoA, as there's less ability to circumvent it through either using raw IPs or experimental protocols like QUIC.
6
Not to mention... I would be hard-pressed to ever go with ISE in the future. Left a very bad taste in my mouth after we spent hundreds of thousands and the AAA was not working (in a previous thread on this forum). That coupled with 4.5 hour upgrades = no go for me (as well as other monotonous things)

Hello, I work for $VENDOR where $VENDOR = {"ForeScout Technologies"}. Perhaps we can be of assistance?

:meeseeks:
7
I was way over looking the idea of using just PEAP. Which does make the most sense (deployed a test this morning). Kind of funny actually because I deployed this like 2 years ago for a different corp, and I didn't even think of it. My mind has been fixed on .1x as of late.


yeah I do not care about EAP-TLS, as this is just for internet. I am not going through the hassle. Even if I did attempt to create a sandbox splash page to allow users to install then proceed to connection. It is just not worth my time.

Currently we are using web-auth and it works like garbage on anything non mobile (and honestly... it sucks for mobile too).

Not to mention... I would be hard-pressed to ever go with ISE in the future. Left a very bad taste in my mouth after we spent hundreds of thousands and the AAA was not working (in a previous thread on this forum). That coupled with 4.5 hour upgrades = no go for me (as well as other monotonous things)
8
Routing and Switching / ISR 4K NBAR
« Last post by LynK on Today at 02:03:52 PM »
Here is a fun QoS problem I have run into.

Lets say a router has a shared MPLS + Internet circuit (100/100mbps). Both are going out the same external interface but in VRFs and sub interfaces.

You can't apply the NBAR policy on the parent External interface because it does not see any protocols in the NBAR protocol analyzer (unless this is a bug). This then forces me to apply the service policy on the sub-interfaces.

 Would it be safe to apply the QoS policy to both sub-interfaces (100mbps), and have them aggregate?

My fear is that I have 50% allocated for voice + video. It would then use 50% on vrf A sub interface A and 50% on vrf B sub interface B.

Thoughts?

here is my current QoS design. This was however assuming percentages based on a single interface policy. I am not sure if sub-interfaces are aggregates of the parents bandwidth. Or am I really going to have to shape out a specific amount of bandwidth for internet, and a separate share for MPLS (example: 80 mbps for internet, 20 mbps for mpls).

Code: [Select]
class-map match-any REALTIME
match protocol rtp audio
match protocol rtp video
match protocol cisco-phone-audio
match protocol webex-meeting
match protocol webex-app-sharing
match protocol webex-media
match protocol telepresence-media
match protocol sip
match protocol sip-tls
match protocol skinny
match protocol sip
match protocol h323
match protocol rtcp
match protocol telepresence-control
match protocol cisco-phone
match protocol cisco-jabber-audio
match protocol cisco-jabber-video
match protocol attribute category voice-and-video
!
class-map match-any MISSION_CRITICAL
match protocol mgcp
match protocol bgp
match protocol smtp
match protocol vmware-view
match protocol vmware-vmotion
match protocol vmware-vsphere
match protocol radius
match protocol ssh
match protocol attribute category netadmin
!
class-map match-any BUSINESS_CRITICAL
match protocol attribute category consumer-internet
match protocol attribute category consumer-file-sharing
match protocol attribute category browsing
match protocol attribute category email
match protocol http
match protocol https
!
class-map match-any STANDARD
class class-default
!
!
!
!
policy-map QOS
class REALTIME
set dscp ef
priority percent 50
!
class MISSION_CRITICAL
set dscp af41
bandwidth percent 25
!
class BUSINESS_CRITICAL
set dscp af21
bandwidth percent 20
!
class STANDARD
bandwidth percent 5
fair-queue
9
We do not manage the Juniper and are wanting to slowly phase everything off of it to our Cisco. We are turning up a new site and want this to be the first one we phase over.
So this begs the question, why not just cut everything over or put the ASA inline behind the Juniper, where you can permit tunneling traffic on the Juniper to allow it to pass through the ASA? Sorry if you've already gone over this at work, but I wasn't in that meeting, so I'll need to catch up on things. :)
10
We do not manage the Juniper and are wanting to slowly phase everything off of it to our Cisco. We are turning up a new site and want this to be the first one we phase over.
Pages: [1] 2 3 ... 10