Good morning!

It’s been a good couple of days and i’m really excited about the stuff i’m learning! . I’m looking to start the INE CCIE-sec bootcamp tomorrow and i’ll be posting about that. I won’t be posting all the notes i make ( ‘coz that wouldn’t make sense to anyone else ) , but i’ll be posting all the caveats and the workarounds that i learn.

Today, i had a bad start. Didn’t get good sleep + a bad dream + my room was really cold ( left the window open ). So my day started out all slow and i spent almost half the day gazing into the monitor and wondering what life was all about. After lunch, i came to my senses and i started reading around and made some notes about the stuff that i learnt . There are a few topics that i studied for the first time , as well as some topics that i revised.

Here’s the list

• PRIVATE VLANs
  • This is a topic which i went through earlier, but i’d forgotten some of the details so i revised it again. HERE’s the link
  • A couple of things to remember here are :
    • Remember that all the members in different Private VLAN’s will all share the SAME IP subnet
    • For 2 communities to talk to each other, the things that must be done are
      • Hell, Put them all in the same community! Duh! ( Sorry i couldn’t help myself there! )
      • Configure an SVI on the switch to which the communities are connected to.
      • Why this is required is because , since the broadcast domains for the communities are separate, ARP requests which are broadcast messages, will not reach their intended destination in the other private VLAN.
        • As a workaround for this, we need to enable , “ip local-proxy arp” -> this command instructs the swx to answer to the ARP requests for clients in the same subnet as the requester. Ex : If 10.1.1.1 sends out an ARP query for a host 10.1.1.15 (present in another PVLAN ), without the “ip local-proxy-arp” command enabled, the swx will assume that since both the source and destination IP addresses of the ARP request are in the same subnet, 10.1.1.15 will reply to the ARP and that the swx doesn’t have to worry about it. Hence, with the local-proxy-arp enabled, the swx assumes that it HAS to reply to the ARP request.
        • For “ip local-proxy-arp” to work, “ip proxy-arp” has to be enabled under the interface. This should be enabled by default, if not, go ahead and enable it manually.
      • So an SVI is required on the switch because it has to answer the ARP queries .
  • There’s a small difference between the concept of private VLAN’s and “switchport protected ” a.k.a ” Private VLAN Edge ” . Here’s the difference.
    • A port configured as a community port  on a  swx has the following restrictions
      • It will not communicate with other ports on the same switch which belong to different PVLAN’s
      • However, if trunking is configured between switches, then if there’s a port on the second swx belonging to the same PVLAN, then they can communicate
      • If there are no other ports on the second switch belonging to the same PVLAN, then no communication takes place
    • Whereas, with the “PVLAN edge” feature, the following restricts are forced upon the switch ports
      • In a switch , 2 ports configured as “switchport protected” , will not communicate with each other
      • In a switch , ports configured as “switchport protected” can still communicate with other ports which are not configured as PVLAN Edges.
      • In a scenario where multiple switches are present, and there are protected ports on different switches, then a protected port on one switch, will be able to talk to all the ports of the other switch ( irrespective of whether that port is a normal or PVLAN edge port ).
• SLA on the ASA
  • This was a new topic for me as i’d just read about it earlier , but i’d never configured it.
  • This concept is super-powerful and i just tested it out today.
  • The purpose of SLA is that , it monitors an IP address. It keeps checking it’s reachablity (once every configurable interval ) .
  • Along with SLA , we touch another command called “track” which is used to keep track of various SLA’s or various Interfaces that we are tracking.
    • ex : Suppose we are attaching “track #1″ to “sla #1″ , if the IP that sla #1 is monitoring goes down, then the track status goes to DOWN.
  • The advantage of having a track is that we can link the track status to a route. Doing this ensures that , when the track status goes DOWN, i.e when the IP reachibility is down, the IP route in the routing table, corresponding to that track ID , is removed!
  • The real world use of this might be a case where, the company’s EDGE firewall ( or router ) is connected to 2 ISP’s. One which is the primary and the other acting as the backup.
    • Suppose we have an SLA ( sla 1 ) monitoring the gateway of our primary ISP. We will also associate a track ID to it ( say track ID 123 )
    • In our routing table, we will have  a default route pointing to the Primary IPS’s gateway. Along with this attach the “track 123″ command to it at the end of the static route , so that the fate of this route, now depends if the gateway is reachable in the first place or not.
    • Next, create a backup default route with a higher metric pointing to the gateway of the backup ISP. ( this is our backup route, which is only used if the primary default route is removed from the routing table ).
    • If there is a problem in reaching the gateway of ISP 1, the following things happen
      • The SLA engine will try and verify it’s reachability for a duration of time (this can be configured)
      • If it’s still not reachable, it will drive Track 123 pointing to that SLA to “DOWN”
      • The default route in the routing table ( the one which the “track 123″ ) will now be removed.
      • The backup default route that we’d configured ( the one pointing the secondary ISP ) , will now become the default route.
  • This ensures that connectivity to the internet still remains, and that all this happens automatically.
  • You can find some data on this here : SLA-MONITOR and TRACK
• I also did some configuration on redundant interface configuration on the ASA. This is pretty straightforward.

Tomorrow, i’m starting the INE Cod Bootcamp as i’ve already told you and i’ll be posting about it soon!

Cheers,

TacACK