Understand VLAN like never before!!

I consider vlan to be a dome like structure in a real world. What will happen if 10 people i.e. human beings are left in a closed dome like structure a.k.a vlan. Yeah, probably they all will survive with food and O2 and they can also talk to each other & share their GF-BF stories.

But the question is why they are able to talk to each other; probably they are all humans and so they understand each other Or probably they are all English speaking dudes. Good. Lets call all these English speaking dudes originated from same family. Can we call them 1 family, OR 1 LAN members common to them all is ENGLISH.

So morally all English speaking dudes can talk to each other in a dome closed structure. Now, assume we add two more people in that dome that adds up to total strength being 12 now. Unfortunately, those two speak only either Hindi or Chinese. Will the 10 English dude be able to talk to and understand those 2 Hindi/Chinese or vice-versa?? Naaaaah!!! Not until some a 1000 years evolution or a new paradigm change on the way they express themselves.

This is like a situation where 10 people in a LAN who all understand English can't talk to 2 people who only understand either Hindi or Chinese. Can we say those 2 are not in a family or VLAN despite being in that dome. Now if you replace those 10 people with a network address in 10.10.10.0 255.255.255.0 and assign them IP from 10.10.10.1 -10 they all will talk to each other beautifully. Eventually the Chinese/Hindi guys will be member of a different family say 10.10.20.0 255.255.255.0 and are deprived of any communication between the two families.

Now , suppose there is one more dome number 2 parallel to above dome number 1. Here we have 2 domes in total but since both are unique independent closed structure, people from dome 1 and 2 can't talk to each other. Assuming there are 10 English speaking people & 2 Chinese/Hindi Speaking  in dome 2 as well, it means it is exact replica of dome 1.
Now the 10 english speaking from dome 1 can't talk to 10 english speaking people in dome 2 & similary from the 2 chinese/Hindi speaking chaps.

What if I create a HOLE in Dome 1 & Dome 2 connecting it through a rubber tube of a Tyre. But the privilege is that the HOLE was created by English people on both the sides so they own the rubber tube/tunnel to communicate with the other side.

The two Chinese/Hindi in both the domes 1/2 won't be able to pass their words to each other since they don't have any hold on the tunnel nor do they have money to dig on their own.

Supposedly, one night the 2+2 Chinese/Hindi speaker on both side got some money miraculously and dug a HOLE which they own. Now 2 Chinese/Hindi Speaking can talk to each other through their independent HOLES( in their respective domes) which they own.

These two independent HOLES( connected via tube)  created by both the Englishmen and the CHINESE/HINDI speaker can be called two ports belonging to two vlans or to two different family.

One day one storm hits both the domes and ENGLISHMEN lose their rubber tube tunnel, therefore, the communication between dome 1 and dome 2 English guys snapped. They were drawing a plan to create more domes but lost contact after the storm passe but the 2 CHINESE/HINDI speaker's tunnel is intact and OK.

For the time being ENGLISHMEN used their policy and offered pizzas to the 2 CHINESE/HINDI speaker's in lieu to use their tunnel for their communication. Since 2 CHINESE/HINDI speaker's got something new for their taste-buds they agreed to share the rubber tube tunnel with the 10 ENGLISHMEN on both the sides.

This way both sides could talk to each other happily without any further disruptions. This common use of tube can be called a trunk which carries information for both the ENGLISHMEN& CHINESE/HINDI family or vlans.

I hope you enjoyed the story and had fun imagining it.

Good Luck!


-Anupam

IP accounting - Cisco Press

Read IP accounting, though not used much these days, but a nice feature on security and inspection level.

Uses:

1. IP accounting L3, which is configured only on outbound and doesn't take into account the traffic terminating or originating on the router itself. Maintains Acitve and Checkpoint database to store the history and active traffic logs,

2. IP Accounting ACL checks the traffic which doesn't match any specific acl. A range of IP address can be provided. Can be put on both ingress and egress ports. Keep incrementing the hits for a subset of address. Collected data is accessible via CLI and SNMP; however, the initial configuration is required via CLI. To retrieve the collection results via SNMP, you need to enable SNMP on the router first. When configuring SNMP, distinguish between read-only access and read-write access.

3. IP accounting MAC for LAN etc. Best for usage billing per IP id per customer. Has only active logs visual feature

4. IP Accounting Precedence: provides IP precedence-related traffic accounting information. The collection per interface consists of the total number of packets and bytes for each of the eight IP Precedence values, separately per direction (send and receive).Sub-interfaces can be helpful for per user.

Link to IP accounting by Cisco Press

Good Luck!

HSRP version 1 & 2 differences

Some good difference:

1.HSRP v2 learns, advertises  millisecond times values which was missing in v1.

2. Vlan is increased from 255 to 4095 which allows to makes more groups.

3. HSRP v2 allows to know which router sent the message because earlier the source message had VMAC 0c07 virtual address.Version 2 includes a 6 byte identifier field that is used to identify the message sending node.

4 HSRP v1 uses multicast address 224.0.0.2(also used by CGMP) to communicate with its peers over the same subnet in a group  & for to exchange hello packets. Now v2 uses 224.0.0.102 in v2. 

5. Uses a new MAC address range 0000.0C9F.F000 to 0000.0C9F.FFFF.

6. HSRP version 2 has a different packet format than HSRP version 1. The packet format uses a type-length-value (TLV) format. HSRP version 2 packets received by an HSRP version 1 router will have the type field mapped to the version field by HSRP version 1 and subsequently ignored.

All you need to do is add one more interface sub-command:

R1(config-if)# standby version 2

But make sure you remember HSRP v2 and v1 are not compatible. So v2 can't make in a group with v1 for gateway load balancing.

Cheers!!

Stateful Protocol Analysis: By Karen Kent

An impressive article on how stateful basically works and what is it good for IDS. Must read for IDPS lovers;

Network IDS part One

Network IDS Part Two

Network IDS Part Three

Network IDS Part Four

network-intrusion-detection-signatures-part-five

By-
Network Intrusion Detection Signatures
Karen Kent Frederick, SecurityFocus

BGP weight attribute manipulation for best path

In this example we will try to manipulate the path choice based on weight metric. We've four routers R1 in AS100, R2 in AS 200, R3 AS 300, R4 AS 400. All routers shares with each other directly connected neighbors and no static/dynamic routing protocol is used anywhere.

R1<>R2

R2<>R3

R3<>R4

R1<>R4

All of them are e-bgp neighbor-ship. 

Weight Attribute:

Weight by default comes up when you have a route originating from a local to AS router. So if your router R xyz has a route to be advertised by you and you use network 'i'-origin then by default a value of 32768 is assigned to it showing that route is directly originated from it and is most preferred with this value. Weight attribute matter only to a router in an AS and doesn't get transferred to other AS. 

Objective:

Router R4 learns about network 223.200.0.0 /16 from two source R1 and R3. It may choose either of them to be a preferred route to reach the former depending upon AS_PATH choice which remains same in count. 

In our case R4 choice by default is 

R4(config)#do sh ip bgp

BGP table version is 2, local router ID is 4.4.4.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

              r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

   Network                Next Hop            Metric LocPrf Weight Path

*  223.200.0.0/16   3.3.3.1                                                     0 300 200 i

*>                              4.4.4.1                                                     0 100 200 i          //best path via R1

Observation:

R4(config)#do sh ip bgp sum

BGP router identifier 4.4.4.2, local AS number 400

BGP table version is 2, main routing table version 2

1 network entries using 101 bytes of memory

2 path entries using 96 bytes of memory

2 BGP path attribute entries using 120 bytes of memory

2 BGP AS-PATH entries using 48 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory

0 BGP filter-list cache entries using 0 bytes of memory

BGP using 365 total bytes of memory

BGP activity 1/0 prefixes, 2/0 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd

3.3.3.1         4       300      14      14                   2        0        0       00:09:20        1

4.4.4.1         4       100      15      14                   2        0        0       00:10:01        1

Solution a two way round:

1. We can use the neighbor sub command under router bgp 400 and give a weight attribute directly for that neighbor.

neighbor 3.3.3.1 weight 4096

Note: All routes from that member will then have same weight attribute. It is more of static hard route manipulation.

2.  We can do it dynamically for specific routes learned from particular ASes. For R4 we will add one more command:

 router bgp 400

 no synchronization

 bgp log-neighbor-changes

 neighbor 3.3.3.1 remote-as 300

 neighbor 3.3.3.1 route-map weight_change in      //by calling a route-map

        I.            Create a route map:

      II.            route-map weight_change permit 10

    III.            match ip address 101

    IV.            set weight 4096

      V.            Follow below ace;

    VI.            access-list 101 permit ip 223.200.0.0 0.0.255.255 any

  VII.            access-list 102 permit ip any any

 

3. One more way is to use AS_PATH in acl and allow specific AS only. This but doesn't achieve our target of dynamic choice of best path rather it only allow certain ASes as per the list.

On R4:

        I.            router bgp 400

      II.            no synchronization

    III.            bgp log-neighbor-changes

    IV.            neighbor 3.3.3.1 remote-as 300

      V.            neighbor 3.3.3.1 filter-list 2 weight 4096   //setting filter-list to filter AS with a weight set

    VI.            Use AS_PATH acl;

  VII.            ip as-path access-list 2 permit ^300            //300 is AS number of R3

Using all the above ideas one case make a path less/more preferred by a router local to an AS when it has more than one way to reach the destination.

Good luck!!