Welcome
First of all, may I welcome you to my site. My name is Chris and I'm from the UK and work as a Systems Engineer for Cisco. This blog was initially created to post up my subnetting technique but has now got more stuff to do with attaining Cisco certifications. Either way I really hope that the content is sufficent for your needs and I look forward to hearing your feedback. If you find that the content really helps you please feel free to donate using the PayPal link on the right.
To view the index of all my articles please click here.
The 95th Percentile - How ISPs charge
Wednesday, 12 October 2011
Hi all,
I've finally got my head around how ISPs charge customers for their traffic. Generally speaking ISPs charge on a flow basis rather than volume. What does this mean? It means that an ISP will charge a customer based on the number of bits passing through their pipes at any particular moment in time (commonly Megabits per second) as opposed to the total volume of traffic the ISP moves for the customer. Why do ISPs prefer a flow? Simply because it protects them from bursty traffic and unpredictable performance. If you was to charge by volume then theoretically you could send little or no data over a period of say 29 days then on the last billing day of the month send all of your traffic in one go. How would ISPs cope?
Interestingly some companies try to negotiate with ISPs a price based on volume. They come up with a suitably large figure, say 800 Megabytes per month and then try and command a lower price-per-megabit. If you do the calculations to convert this to Megabits per second we get (800 x 8 / 30 / 24 / 60 / 60) = 0.0025Mbps which in reality is not much at all.
We've now established why ISPs use a flow-based calculation. Now we need to understand how ISPs charge.
ISPs generally take traffic statistics every 5 minutes in both the inbound and outbound directions. This means over a billing month of 30 days there are (60/5 * 24 * 30) = 8640 lines of statistics per customer interface.
What the ISP does is arrange the 8640 lines in order of size, that is, from highest Mbps to lowest Mbps. The ISP then removes the top 5% of the lines and bills the customer for the next line which is the 95th percentile. This is done for both inbound and outbound traffic and whichever is highest the ISP chooses as the charge point. Those that are savvy may realise that the customer is actually allowed to burst for a period of time without penalty. If we say the top 5% of statistics are not taken into account (8640 * 0.05 = 432), and each statistic is 5 minutes, then the customer has effectively 432 * 5 = 2160 minutes or 36 hours in which to burst until their hearts are content.
For those customers with multiple connections (not in a bundle) then there are two chargeable models; cumulative and aggregate.
Cumulative charging takes the above example and repeats it for each individual connection, a simple A + B approach. Let's say that the 95th percentile of circuit A is 500Mbps and for B it is 800Mbps and the price per Megabit is £1 then the customer will be charged (£1 x 500) + (£1 x 800) = £1300.
Aggregate charging differs slightly. For each of the 8640 lines of statistics for each connection, those lines are added together to give one set of statistics for all connections. The 95th percentile operation is carried out on this set to give the charge point.
Which model you choose is down to how bursty your traffic is, whether you are using back-up links etc. I would say that if there isn't much correlation between your connections (i.e. they're not a backup connection to another) and your traffic is predictable then a cumulative model would suit best. However, if your traffic is bursty in nature and you are using a backup connection with the same ISP then an aggregated model is better suited. If you had a backup connection that has been unused for the majority of the month and on the last week of the billing month the primary connection fails you could be bursting beyond your 36 hours grace period on the backup connection and then if using the cumulative model be charged for very high data rate when over the course of the billing period the link was mostly idle.
Some customers tend to ask for an average calculation to be done. For those that burst under their free 36 hours per month then the 95th percentile works better for you as the burst period is removed from the calculation. If using the average calculation in this case the customer will be charged more. Where the average works in the customer's favour is with those that burst over their free 36 hours as the ISP can then charge at the higher price point, however, ISPs tend not to do this as they wish to protect themselves from the bursty nature of some customer's traffic and provide more predictable behaviour.
I hope this helps you understand the 95th percentile and why it is used.
Posted byChris Bloomfield at 12:21 3 comments
Labels: 95th, 95th percentile, Cisco, how isp charge, isp, juniper, percentile
CCIE - Warm Up Phase - Multicast
Tuesday, 3 May 2011
Some general notes from the ATC -
(*,G) = I know what group I want to join but I don't know who is sourcing that traffic
Shared Tree uses shortest path to the RP and all traffic passes through the RP
Source tree uses shortest path to the source and traffic may or may not pass through the RP
Bi-directional PIM uses Shared Trees only
Multicast Source Discovery Protocol (MSDP) is a logical peering between RPs in order to exchange Source Active (SA) information. RPF checks are used to prevent loops. Additionally, able to limit or filter SAs. Specifiy the MSDP peer using "ip msdp peer
Anycast RP - RPs use same IP address. The IGP determines which RP is "closest". If one RP fails, the other RP will be used once IGP reconverges. Used in conjunction with MSDP for exchanging information.
Useful commands:
show ip pim neighbor
show ip pim interface
show ip pim rp mapping
show ip mroute
debug ip mpacket (may need to use "no ip mroute-cache" to see thru-traffic)
debug ip pim
Auto-RP, by default, will not work in a pure Sparse Mode domain as router will not join 224.0.1.39 and 224.0.1.40 as it doesn't know of an RP. However, without joining those groups it won't know what the RP is. There are three workarounds:
a. Default RP assignment where you assign a static RP for 224.0.1.39 and 224.0.1.40 but this defeats the purpose of Auto-RP
b. Configure sparse-dense-mode. This acts as dense mode for those groups with no RP (e.g. 224.0.1.39 and 224.0.1.40).
c. Configure ip pim autorp listener which automatically goes in dense mode for 224.0.1.39 and 224.0.1.40.
Sample Network
--------------
R1--R2--R3--R4--R5--R6
R3 is RP on Lo0 interface. All devices configured with "ip pim rp-address 150.1.3.3" including R3 itself.
All interfaces connected to another router confogured for PIM Sparse Mode.
On R1 configure "ip igmp join-group 224.101.101.101".
R3 should now have a (*,224.101.101.101) as will all routers in the path between R1 and R3.
On R6 try pinging 224.101.101.101 which effectively makes R6 a source for the 224.101.101.101 group.
R3 should now have a (S,G) entry (assume R6 interface is 155.1.146.6) the entry will be (155,1,146,6, 224.101.101.101).
You could use the "ip igmp static-group" command but this will not respond t pings, however, traffic is still processed the normal way and you ought to be able to see the (*,G) and (S,G) entries associated with the static group.
8.1 - A 3560 requires "ip multicast-routing distributed" to be configured.
To test a configuration make an interface join a group and try to ping that group from another router. that interface must also be configured for PIM. What happens here is the interface acts as a host which is listening to a multicast group and the router that is pinging that group address is acting as the multicast source. Example:
int lo0
ip pim dense-mode
ip igmp join-group 224.10.10.10
8.2 If the RPF check fails (i.e. the IGP prefers a path to a source via a different interface, maybe because PIM is not enabled on that interface) then you could always add a static route to the mroute table.
ip mroute 155.1.146.0 255.255.255.0 155.1.0.4
In this example on R5, the IGP preferred a route in EIGRP via the point-to-point serial link to R4. However, PIM was not enabled on that interface but instead on the frame Relay cloud between R4 and R5. Hence, multicast traffic was attempting to go over the Frame Relay cloud but was failing the RPF check (e.g. 155.1.146.6 is meant to be reachable via the point-to-point link and not the Frame Realy cloud).
To change how often a router checks RPF use the "ip multicast rpf interval" command.
To configure a router to perform triggered RPF checks after a topology change and specify a maximum delay use "ip multicast rpf backoff
8.3 - There is a nother RPF failure but that is because R5's Lo0 interface was being advertised as a /32 by OSPF and therefore was the longest match when compared to the /24 advertised by EIGRP. By changing the OSPF network type to point-to-point under the Lo0 interface of R5, the RPF check passed and traffic flowed.
To specify a traffic limit when the Shortest Path Tree (SPT) is used (switched over to) use the "ip pim spt-threshold" command.
8.4 - note that Dense Mode uses (*,G) tuples and Sparse Mode uses (S,G) tuples. to specify which groups an RP can be an RP for, create an access-list and apply that to the rp-address command:
ip access-list standard ACL_ALLOWED_GROUPS
permit 224.0.0.0 0.0.0.255
!
ip pim rp-address 150.1.5.5 ACL_ALLOWED_GROUPS
8.5 - the PIM Assert message tells a shared segment which router should be forwarding on that segment for that particular group. The tiebreak on this is the administrative distance used to reach the source. So, for example, you had a device using EIGRP and one using OSPF, the one using EIGRP would win the assertion due to the lower AD (90 versus 110). To change this you would need to alter the AD of the routing protocol.
8.6 - The Accept RP tells a router to only accept specific groups from trying to join an RP.
For example, if R5 Lo0 is the RP (150.1.5.5) and you only wanted groups 224.10.10.10 and 224.110.110.110 to be able to reach that RP use the following:
ip access-list standard ACL_ACCEPT_RP
permit 224.10.10.10
permit 224.110.110.110
!
ip pim accept-rp 150.1.5.5 ACL_ACCEPT_RP
8.7 - The PIM DR Election process is pre-emptive, unlike OSPF DR election. The winner is the router with the highest priority (default of 1) and if they are tied then the router with the highest IP address will be the PIM DR.
ip pim dr-priority
The "show ip pim interface
8.8. The PIM Accept Register is configured on a RP and tells the RP which sources can register with it. If a source tries to register with the RP that is not on the register you will see Register-Stop messages (assuming "debug ip pim" is configured).
8.9 Multicast tunnelling is straightforward. Try using ip unnumbered on the tunnel as its IP address. Must ensure PIM is configured on tunnel interface and make the tunnel interface passive under the routing process. May also need a static mroute to ensure that the RPF checks do not fail.
Posted byChris Bloomfield at 16:59 0 comments
Labels: CCIE, ine, multicast, pim, rpf, shared tree, source tree, spt
CCIE - Warm-Up Phase - BGP
Tuesday, 26 April 2011
Hi,
I am pretty happy with BGP but still there are a few things that I need to get into my head.
7.5 - Disable Connected Check - this allows eBGP peers to use an IP address to peer that is not directly connected to the neighbor (e.g. a loopback interface). The difference between this and ebgp-multihop is that the TTL is not adjusted for disable-connected-check and that eBGP sessions will not form over transit routers.
7.8 - The bgp cluster-id is applied to the route reflector only.
7.9 - The confederation AS is used in the "router bgp" command and the bgp-confederation identifier refers to the proper AS. You must also specify bgp confederation peers otherwise the adjacency won't come up. In addition, confederation peers are treated as eBGP neighbors and should use directly connected interfaces, otherwise need to use things like update-source and ebgp-multihop.
7.11 - Instead of using next-hop-self you can create a route-map to "set ip next-hop" and apply that to the neighbor (e.g. neighbor 1.2.3.4 route-map ROUTE_MAP_NAME in/out"
7.12 - iBGP synchronization - Do not advertise a BGP route unless it is also learned by the IGP running in the network. In essence this requires the edge router to redistribute the eBGP routes into the IGP in order for iBGP to advertise the routes. Be careful when redistributing routes into IGP. Use an AS PATH access-list:
ip as-path access-list 1 permit ^_54
!
route-map MATCH_AS_PATH permit 10
match as-path 1
!
router eigrp 100
redistribute bgp 100 metric 100000 1000 255 1 1500 route-map MATCH_AS_PATH
Posted byChris Bloomfield at 08:52 0 comments
CCIE - Warm-Up Phase - OSPF
Wednesday, 20 April 2011
This is in relation to INE Workbook 1 and their 48 week program to get up to speed with passing the CCIE exam.
What have I learned?
6.1 - A network statement of "network 0.0.0.0 0.0.0.0 area 0" gets changed to "network 0.0.0.0 255.255.255.255 area 0" which is basically a single network statement that covers all interfaces.
6.2 - By default Frame Relay defaults to an OSPF network type of non-broadcast. This means that a DR/BDR is elected, however, hellos are sent as UNICASTS therefore you must configure static neighbor commands. This needs to be done only on one end of the link but it may be best practice to configure it at both ends for clarity. In addition, as a DR is elected it does not change the next-hop value when it sends out Type 2 LSAs hence spoke routers need a path to the next-hop value via the PVC to the hub (e.g. frame-relay map ip 155.1.0.4 105 -- this will send traffic to 155.1.0.4 via DLCI 105 which is the PVC to R5 which is the hub for this network).
6.4 - Point-to-point uses multicast hellos and no need for DR/BDR election or neighbor statements.
6.5 - Point-to-multipoint. As this is over Frame Relay and the initial Frame Relay maps did not include the "broadcast" keyword no adjacencies formed. Point-to-multipoint uses multicast hellos so you have to specify the "broadcast" keyword. There are also no DR/BDR elections so the hub (R5 in this case) changes the next-hop to itself (155.1.0.5). As each router (R1 to R4) has a Frame Relay map to R5 full-reachability is made.
6.6 - Point-to-multipoint non-broadcast. The only difference here is that it sends hellos as unicast and requires a neighbor statement.
6.7 - Changing the network type on Loopback interfaces to point-to-point advertises the network with its correct mask (in this example /24) rather than the default Loopback type which advertises them as a stub with a /32 even if they are not configured as /32.
6.8 - The reference bandwidth is configured in Mbps.
6.10 - OSPF Path selection with Bandwidth - Change the bandwidth on an interface that RECEIVES the LSA and that is downstream from the device you wish to be affected (e.g. this example requires R6 to route via R1 so change the bandwidth value on R1 Se0/0 to a greater value to affect the overall cost. Note that R1, R4, and R6 share an Ethernet segment)
6.11 - Changing the cost per neighbor. To find out what cost OSPF would assign a bandwidth value change the bandwidth on an interface and use "show ip ospf interface
6.12 - If a router connects two areas together and neither of those areas are Area 0 then the ABR will not act as an ordinary ABR and will not forward Inter-Area routes as all Inter_Area routes must be advertised via Area 0. Therefore you need to use a Virtual Link.
6.13 - OSPF Path Selection with Non-Backbone Transit Areas. After the virtual link was formed and I adjusted some costs on R4, routes to SW2 were being routed via Area 1 (specifically, via R4) and not to R1 even though that link is effectively Area 0 as it is a virtual link. To allow the use of the virtual link you must use "no capability transit" command at BOTH ends of the virtual link.
6.14 - OSPF virtual links will not come up if the cost used to reach the other end of the virtual link is 65535 which is the maximum cost associated with an interface. You must therefore change the OSPF cost at BOTH ENDS of the virtual link.
Posted byChris Bloomfield at 16:58 0 comments
Labels: CCIE, ine, ine workbook 1, ospf, virtual link
RIP - Adjusting default timers
Saturday, 9 April 2011
In my last post about RIP I mentioned quite a few different bits of RIP. Here I just want to focus on changing the timers and how to override the timers.
You can adjust your timers using the timers basic update invalid holddown flush under the routing process:
router rip
version 2
timers basic 30 90 120 120
This will set the update to 30 secs, invalid to 90 secs, holddown to 120 secs, and flush to 120 secs.
What would happen if you need to change that behaviour on just one link? Well, we can configure the update timer under the interface:
interface fa0/0
ip rip advertise 30
This then changes the advertise time to 30 seconds but note that this doesn't change the other timers, only the advertise time!
Posted byChris Bloomfield at 07:56 0 comments
PPP Authentication - Using AAA
Monday, 21 March 2011
Here we'll try to authenticate a session between two routers. One side of the router will use RADIUS while the other will use TACACS+. The side using RADIUS will be configured using a AAA server group. The TACACS+ server will be globally configured. Both RADIUS and TACACS+ use "cisco" as the password.
Router 1
1. Configure a new AAA model
aaa new-model
2. By default, the "aaa new-model" command will require local authentication on the console port. To override this, and save us from locking ourselves out, we must configure specific console authentication and the easiest way to do that is by using "none".
aaa authentication login CONSOLE none
!
line vty 0 4
login authentication CONSOLE
3. Configure a RADIUS server group called MY_RADIUS_GROUP and ensure that the RADIUS server at 192.168.1.1 only applies to this group.
aaa group server radius MY_RADIUS_GROUP
server-private 192.168.1.1 key cisco
4. Configure AAA to authenticate PPP sessions against the RADIUS server group and if that fails it should try the local database.
aaa authentication ppp PPP_AUTH group MY_RADIUS_GROUP local
5. Configure the phyiscal interface to use the AAA authentication session
interface s0/0
ppp authentication PPP_AUTH
Router 2
1. Configure a new AAA model
aaa new-model
2. By default, the "aaa new-model" command will require local authentication on the console port. To override this, and save us from locking ourselves out, we must configure specific console authentication and the easiest way to do that is by using "none".
aaa authentication login CONSOLE none
!
line vty 0 4
login authentication CONSOLE
3. Configure a TACACS+ server group globally at 192.168.1.2
tacacs-server host 192.168.1.2 key cisco
4. Configure AAA to authenticate PPP sessions against the TACACS+ server and if that fails it should try the local database.
aaa authentication ppp default group tacacs local
5. Configure the phyiscal interface to use the AAA authentication session
interface s0/0
ppp authentication PPP_AUTH
Posted byChris Bloomfield at 14:17 1 comments
When to use access-lists or prefix-lists
Sunday, 20 March 2011
Here's a great a bit of info that I pulled from INE's own Brian McGahan that is is worth remembering. Thanks Brian!
Some applications you can use both access-lists and prefix-lists. In general, anytime you are matching a route, like with a route-map for redistribution, a route-map for BGP, or a distribute-list, you should use a prefix-list. This is what they were designed for. An access-list should be used any time you’re trying to match traffic, or with other non-routing related applications.
Source: http://ieoc.com/forums/t/15006.aspx
Posted byChris Bloomfield at 08:31 0 comments
Labels: access-lists, ine, prefix-lists
PPPoE Server and Client
Saturday, 19 March 2011
I've done a load of Cisco 877 configurations in the past on ADSL lines and wondered how all of the virtual template stuff works so here's a lesson as to how to configure PPPoE Server and Client with the Server providing the Client with an IP address using DHCP.
We will also get the Server to authenticate the Client using CHAP and the Server will rate-limit the Client to a maximum of 10 sessions per minute over a period of 5 minutes.
Let's start with the Client as it is the least amount of work.
Client Tasks
1. Configure a Dialer interface
a. It should receive the IP address from the Server
b. Have PPP configured
c. Be part of a Dialer Pool
d. Set the CHAP hostname
e. Set the CHAP password
interface Dialer1
ip address dhcp
encapsulation ppp
dialer pool 1
ppp chap hostname Router1
ppp chap password cisco
2. Tie the Dialer to a physical interface
a. Remove any IP address from the interface
b. Enable PPPoE
c. Configure PPPoE to match the Dialer Pool
interface FastEthernet0/1
no ip address
pppoe enable
pppoe-client dial-pool-number 1
Server Tasks
1. Configure a Virtual Template interface
a. Apply an IP address
b. Apply PPP encapsulation
c. Enable CHAP authentication
interface Virtual-Template1
ip address 192.168.1.1 255.255.255.0
encapsulation ppp
ppp authentication chap
2. Create a Broadband Aggregation Group
a. Give the group a name
b. Tie the Virtual-Template to the group
c. Throttle the client to 10 sessions per minute over a period of 5 minutes.
bba-group pppoe MY_BBA_GROUP
virtual-template 1
sessions per-mac throttle 10 60 300
3. Configure the physical interface connected to the client
a. Tie the physical interface to the BBA group
interface FastEthernet0/1
pppoe enable group MY_BBA_GROUP
4. Create a DHCP pool for the client
a. Exclude the IP address assigned to the Virtual Template interface
ip dhcp excluded-address 192.168.1.1
ip dhcp pool MY_PPPoE_POOL
network 192.168.1.0
5. Create a username/password pair for Router1 for authentication
username Router1 password cisco
That's it. It takes a little while for it to kick in but worth trying to lab.
Cheers,
Chris
Posted byChris Bloomfield at 14:34 1 comments
Labels: ppp, pppoe, pppoe client, pppoe server
PPP Authentication - PAP and CHAP
Friday, 18 March 2011
I don't really use serial interfaces in my day-to-day job so when it comes to lab questions regarding PPP, HDLC, and Frame Relay I am immediately horrified.
Here's the question given:
1. Enable PPP encapsulation for the Serial link connecting R4 and R5 and use the IP subnet 155.1.45.0/24 for this link.
2. R4 should attempt to authenticate R5 using PAP and then CHAP. R5 should refuse PAP authentication and use CHAP.
3. Make sure R4 uses an alternate CHAP hostname R4CHAP.
4. Use the name R5CHAP and the password of CISCO to accomplish this.
5. R5 should authenticate R4 using PAP only. R4 should use the name R4PPP and the password of CISCO.
Let's say that s0/0 is the interface at either end and R4 is the DCE.
Step 1:
Apply PPP, clock rate on R4, and IP address.
R4:
interface s0/0
encapsulation ppp
clock rate 64000
ip address 155.1.45.4 255.255.255.0
R5:
interface s0/0
encapsulation ppp
ip address 155.1.45.5 255.255.255.0
Step 2:
R4 needs to authenticate R5 using PAP, and if it is refused, should use CHAP. R5 will be configured to refuse PAP authentication from R4.
R4:
interface s0/0
encapsulation ppp
clock rate 64000
ip address 155.1.45.4 255.255.255.0
ppp authentication pap chap
R5:
interface s0/0
encapsulation ppp
ip address 155.1.45.5 255.255.255.0
ppp pap refuse
Step 3:
R4 needs to specify a CHAP hostname of R4CHAP. If this wasn't specified then the CHAP hostname would be set as the hostname of the router (in this case, R4).
R4:
interface s0/0
encapsulation ppp
clock rate 64000
ip address 155.1.45.4 255.255.255.0
ppp authentication pap chap
ppp chap hostname R4CHAP
R5:
interface s0/0
encapsulation ppp
ip address 155.1.45.5 255.255.255.0
ppp pap refuse
Step 4:
R5 should respond with a CHAP hostname of R5CHAP and a CHAP password of CISCO. Therefore on R4 we must configure a username/password pair for R5's details. What isn't obvious is that R5 needs a username/password pair for R4's details. In this case the R4 CHAP hostname is R4CHAP and the password must match R5's CHAP password which is CISCO.
R4:
username R5CHAP password CISCO
!
interface s0/0
encapsulation ppp
clock rate 64000
ip address 155.1.45.4 255.255.255.0
ppp authentication pap chap
ppp chap hostname R4CHAP
R5:
username R4CHAP password CISCO
!
interface s0/0
encapsulation ppp
ip address 155.1.45.5 255.255.255.0
ppp pap refuse
ppp chap hostname R5CHAP
Step 5:
R5 wants to authenticate R4 using PAP and R4 responds with a PAP username of R4PPP and a PAP password of CISCO.
R4:
username R5CHAP password CISCO
!
interface s0/0
encapsulation ppp
clock rate 64000
ip address 155.1.45.4 255.255.255.0
ppp authentication pap chap
ppp chap hostname R4CHAP
ppp pap sent-username R4PPP password CISCO
R5:
username R4CHAP password CISCO
!
interface s0/0
encapsulation ppp
ip address 155.1.45.5 255.255.255.0
ppp pap refuse
ppp chap hostname R5CHAP
ppp authentication pap
That's it. Not too bad but worth working through to see how it all fits together.
Posted byChris Bloomfield at 13:16 0 comments
Labels: authentication, chap, pap, ppp
Multicast RPF
Wednesday, 16 March 2011
Right then, I'm happy with RPF as a principle and that the router checks the interface on which it receives multicast traffic and consults its routing table to see if that interface would be used to reach the multicast source.
What I didn't know (or at least I hadn't remembered) until now is that when there are equal-cost paths to the multicast source (e.g. OSPF, EIGRP etc) the router must pick one of them for Multicast RPF. Which one does it pick? It picks the one with highest neighbouring router ID.
For example, let's say that the multicast RP is located on 192.168.1.0/24 network. You downstream router receives two equal-cost routes for that subnet, one from R1 with a router-id of 1.1.1.1 and the other from R2 with a router-id of 2.2.2.2. The router will pick the interface connected to R2 as it has the highest router-id.
You can frig this by using tunnelling but that is a whole new ball game and one I'm not going into right now.
Posted byChris Bloomfield at 11:06 0 comments
CCIE Study - Written v4 Chapters 1 to 3 - 22/02/10
Tuesday, 22 February 2011
Well I've learned lots actually, or more accurately put, I remembered lots of stuff that I had forgotten. Stupid stuff that I should have known right off the bat but slipped the mind.
Etherchannel
Cisco recommends for PAgP that both ends of the link be configured as Desirable.
Ethernet Basics
802.3ab defines GigabitEthernet over UTP whereas 802.3z defines GigabitEthernet over Fibre. 802.3u defines FastEthernet.
MAC addresses are in canonical format which means that the most significant bit is on the right. Take the first two hexidecimal values from a MAC address and convert them to binary to give you an 8-bit string. The Individual/Group bit (I/G) is the right-most bit (i.e. the most signficant bit). If that is set to 0 then the MAC address is a unicast. If it is set to 1 then the MAC address is a broadcast or multicast. The second right-most bit is the Universal/Local bit (U/L). If this is set to 0 then the MAC address has been assigned by the vendor. If it is set to 1 then the MAC address has been administratively assigned.
Q-in-Q
VPLS and EoMPLS offer alternatives to Q-in-Q.
Spanning Tree
If a switch does not have any trunks configured at boot time but has the "spanning-tree root primary" command issued the priority of the switch will go to 24576 which is 8192 less than the default priority of 32768. If a trunk link is then formed and a switch has a higher priority then it will become the root and not the one with the root primary macro.
If you want to configure BPDUGuard at interface level you must take off any interface-level PortFast configuration first.
If running 802.1D and the root port does not receive any BPDUs the switch will wait for the Max Age timer to expire (default 20 seconds) before using another port.
Port priority and port number when used as a tiebreaker are those on the advertising switch and not on the switch that receives the BPDU.
If a root port fails then switchover to an alternative port is almost immediate.
SPAN/RSPAN
Destination ports do not forward Layer 2 protocols such as CDP, DTP, VTP, and STP.
Up to 64 destination ports may be configured.
The monitor session number can range between 1 and 66.
VLANs
The only VLANs that can be pruned are VLANs 2-1001. VLANs 1, and 1002-1005 are not prune eligible and can never be deleted.
Posted byChris Bloomfield at 18:37 0 comments
Labels: CCIE
Frame Relay - BECN/FECN
Saturday, 19 February 2011
BECN - Backward Explicit Congestion Notification is a bit in the Frame Relay header that is set by the destination and sent BACK to the originator indicating congestion in the path and to slow down transmission of data.
FECN - Forward Explicit Congestion Notification is a bit in the Frame Relay header that is set by the sender and is FORWARDED to the destination to indicate congestion in the path and to slow down requests for data.
Note that these are set by a Frame Relay switch in general so are received by a router rather than sent by a router.
Posted byChris Bloomfield at 14:27 0 comments
Labels: becn, fecn, frame relay
How to calculate multicast MAC address
Thursday, 17 February 2011
Hi,
It's been a while but here's a quick post on how to calculate a multicast MAC address from an IP address.
The first half of a multicast MAC address is 01-00-5E so we need to work out the second half.
To do this we need to convert the last 23 bits of the IP address in question. If you think about this we are not using the high order bit in the second octet which carries a value of 128. Therefore it must follow that a value of 6 in the second octet must be the same as 134 in the second octet as the high-order bit (i.e. a value of 128) is ignored.
So this leads to a simple method. Let us try and convert 192.168.35.1 to a multicast MAC address
1. Start with a half-filled multicast MAC address of 01-00-5E-XX-YY-ZZ
2. To calculate the value of XX take the second octet. If the value of the second octet is greater than 128 then subtract 128 from the second octet. In this example, the value of 168 is greater than 128 so we subtract 128 from 168 to give us a value of 40. Convert this value to hexadecimal. Decimal 40 = 0x28. Our multicast MAC address is now 01-00-5E-28-YY-ZZ
3. To calculate the value of YY take the third octet and convert it to hex. In this example the value is 35 which equals 0x23. Our multicast MAC address is now 01-00-5E-28-23-ZZ
4. To calculate the value of ZZ take the fourth octet and convert it to hex. In this example the value is 1 which equals 0x01. Our multicast MAC address is now 01-00-5E-28-23-01
So 192.168.35.1 has a multicast MAC address of 01-00-5E-28-23-01.
Can you spot an issue here? Hopefully you can. Basically any IP address with 40.35.1 or 168.35.1 as the last three octets carry the same multicast MAC address so you have potentially 32 addresses with the same multicast MAC address!
Back to the books for me!
Good luck with your studies.
Posted byChris Bloomfield at 20:48 2 comments
Labels: 01-00-5E, calculate multicast MAC, machine, multicast, multicast MAC address
