Here is a useful list of multicast IP's
224.0.0.1 - All multicast systems on the subnet
224.0.0.2 - All multicast Routers on the subnet
224.0.0.4 - All Distance Vector Multicast Routing Protocol routers
224.0.0.5 - All OSPF routers
224.0.0.6 - All OSPF DR/BDR routers
224.0.0.9 - All RIPv2 routers
224.0.0.10 - All EIGRP routers
224..0.0.13 - All PIMv2 routers
224.0.1.1 - NTP time servers
224.0.1.39 - for Auto-RP rp-announce
224.0.1.40 - for Auto-RP rp-discovery
Wednesday, July 21, 2010
Tuesday, July 20, 2010
CCNP - ENTERPRISE - Multicast - 224.0.1.40, where did that come from??
When you are configuring PIM in Sparse-Dense mode every router automatically subscribes to the Rendezvous Point Discovery group 224.0.1.40 .
This why when you do #sh run you may have entries for:
!
ip igmp join-group 224.10.50.1
ip igmp join-group 224.10.70.1
!
But when you do - #sh ip igmp groups
You acually get listed:
Group Address
224.10.50.1
224.10.70.1
224.0.1.40
Confusion cleared!
This why when you do #sh run you may have entries for:
!
ip igmp join-group 224.10.50.1
ip igmp join-group 224.10.70.1
!
But when you do - #sh ip igmp groups
You acually get listed:
Group Address
224.10.50.1
224.10.70.1
224.0.1.40
Confusion cleared!
CCNP - ENTERPRISE - Multicast - Work out IP Multicast MAC addresses
You can work out what the multicast MAC address is for a given multicast IP by using the following steps.
1) First stage is to remember that all multicast MAC addresses start 01-00-5e totalling 25bits (IANA allocated 24 bits plus an extra bit set to zero so this totals 25 bits). What remains is 23 bits to use for the MAC (48bits in total).
2) Take your multicast IP and right it out in binary e.g.
- 224.10.60.3 = 1110 0000. 0 | 000 1010.0011 1100.0000 0011
23-bits to convert to a MAC
3) Now convert each group of 4 bits to Hex working from right to left
1110 0000. 0 | 000 1010.0011 1100.0000 0011
- 0 a 3 c 0 3
4) Combine the converted Hex with the fixed multicast MAC bits:
- 01-00-5e-0a-3c-03
There you go. Relatively easy. Just remember that due to the 24 bits plus the zero bits that its best to work from right to left and you shouldn't go wrong.
I don't know, since I've not taken the exam yet, but to me this has exam question written all over it. Practice this so you can create multicast MAC addresses from a given multicast IP and you should have a mark in the bag.
1) First stage is to remember that all multicast MAC addresses start 01-00-5e totalling 25bits (IANA allocated 24 bits plus an extra bit set to zero so this totals 25 bits). What remains is 23 bits to use for the MAC (48bits in total).
2) Take your multicast IP and right it out in binary e.g.
- 224.10.60.3 = 1110 0000. 0 | 000 1010.0011 1100.0000 0011
23-bits to convert to a MAC
3) Now convert each group of 4 bits to Hex working from right to left
1110 0000. 0 | 000 1010.0011 1100.0000 0011
- 0 a 3 c 0 3
4) Combine the converted Hex with the fixed multicast MAC bits:
- 01-00-5e-0a-3c-03
There you go. Relatively easy. Just remember that due to the 24 bits plus the zero bits that its best to work from right to left and you shouldn't go wrong.
I don't know, since I've not taken the exam yet, but to me this has exam question written all over it. Practice this so you can create multicast MAC addresses from a given multicast IP and you should have a mark in the bag.
CCNP - ENTERPRISE - Multicast - #sh ip mroute
To determine the state of multicast on your router use #sh ip mroute
Options are as follows:
summary - One liner for each entry int the IP Multicast routing table
count - View stats regarding group and source, packets, and bits per second
active - Displays rates that active sources are sending to multicast groups
Options are as follows:
summary - One liner for each entry int the IP Multicast routing table
count - View stats regarding group and source, packets, and bits per second
active - Displays rates that active sources are sending to multicast groups
CCNP - ENTERPRISE - Multicast - Notes
This article is more of a reminder to me on some of the finer points of multicast show commands.
1) #sh ip mroute - in the output of this cmd the neighbor stated in the RPF field is the upstream router to the multicast source
2) #sh ip mroute summary - displays active multicast groups
3) #sh ip pim interface count - The H parameter identifies the IP-Multicast, MLS-enabled interfaces
4) #sh ip pim int s0/0 - displays the IP of the next hop router, number of PIM neighbors discovered, PIM mode
5) IGMPv3, receivers signal membership to a multicast host group in either Exclude or Include mode
1) #sh ip mroute - in the output of this cmd the neighbor stated in the RPF field is the upstream router to the multicast source
2) #sh ip mroute summary - displays active multicast groups
3) #sh ip pim interface count - The H parameter identifies the IP-Multicast, MLS-enabled interfaces
4) #sh ip pim int s0/0 - displays the IP of the next hop router, number of PIM neighbors discovered, PIM mode
5) IGMPv3, receivers signal membership to a multicast host group in either Exclude or Include mode
Thursday, July 15, 2010
CCNP - ENTERPRISE - eBGP multi-hop behaviour
EBGP peers are generally connected via their physical addresses. This is because there wouldn't be any internal routing (eigrp, ospf etc) between the 2 AS's and so the router wouldn't know how to connect to a loopback address located in a different AS.
But what if for resilience purposes you want 2 eBGP peers to establish a neighbor state via their loopback addresses, or for that matter you want to peer with an eBGP that is more than one router away? eBGP peers are usually one hop away. The 'ebgp-multihop' command allows you to extend the number hops an eBGP packet can pass through before the TTL expires. The default TTL is 1 and 1 hop gets you to the physical interface on your eBGP peer, no further.
Take this 2 router example, connecting to loopback interfaces:
AS100 - lo0 =10.1.1.1/32------(R1)>>>><<<<(R2)--------lo0 = 10.20.20.2/32 - AS200
The first step is to apply a static route on your routers so the router knows where to send traffic for the eBGP peer's loopback address.
R1(config)#ip route 10.20.20.2 255.255.255.255 int s0/0
!
R2(config)#ip route 10.1.1.1 255.255.255.255 int s0/0
Next, you go in to the BGP process and enter the your configuration for the eBGP peer:
R1(config)#router bgp 100
R1(config-router)#neighbor 10.20.20.2 remote-as 200
R1(config-router)#neighbor 10.20.20.2 update-source lo0
R1(config-router)#neighbor 10.20.20.2 ebgp-multihop 5
!
Do likewise on the remote peer:
R2(config)#router bgp 200
R2(config-router)#neighbor 10.1.1.1. remote-as 100
R2(config-router)#neighbor 10.1.1.1 update-source lo0
R2(config-router)#neighbor 10.1.1.1 ebgp-multihop 5
!
In this example you are increasing the TTL to 5 allowing the packet to traverse 5 hops before the packet is dropped. This will in turn allow you get to your peer's loopback address and establish a neighbor state.
For eBGP peers that are more than one router away you still need to apply the 'ebgp-multihop' command on the 2 peer routers but you also need to make sure you have routes for the loopback interfaces of the eBGP peers on the intermedaite routers, otherwise you will end up with a 'black hole' and packets being dropped as there is no vaild route to the peers.
But what if for resilience purposes you want 2 eBGP peers to establish a neighbor state via their loopback addresses, or for that matter you want to peer with an eBGP that is more than one router away? eBGP peers are usually one hop away. The 'ebgp-multihop' command allows you to extend the number hops an eBGP packet can pass through before the TTL expires. The default TTL is 1 and 1 hop gets you to the physical interface on your eBGP peer, no further.
Take this 2 router example, connecting to loopback interfaces:
AS100 - lo0 =10.1.1.1/32------(R1)>>>><<<<(R2)--------lo0 = 10.20.20.2/32 - AS200
The first step is to apply a static route on your routers so the router knows where to send traffic for the eBGP peer's loopback address.
R1(config)#ip route 10.20.20.2 255.255.255.255 int s0/0
!
R2(config)#ip route 10.1.1.1 255.255.255.255 int s0/0
Next, you go in to the BGP process and enter the your configuration for the eBGP peer:
R1(config)#router bgp 100
R1(config-router)#neighbor 10.20.20.2 remote-as 200
R1(config-router)#neighbor 10.20.20.2 update-source lo0
R1(config-router)#neighbor 10.20.20.2 ebgp-multihop 5
!
Do likewise on the remote peer:
R2(config)#router bgp 200
R2(config-router)#neighbor 10.1.1.1. remote-as 100
R2(config-router)#neighbor 10.1.1.1 update-source lo0
R2(config-router)#neighbor 10.1.1.1 ebgp-multihop 5
!
In this example you are increasing the TTL to 5 allowing the packet to traverse 5 hops before the packet is dropped. This will in turn allow you get to your peer's loopback address and establish a neighbor state.
For eBGP peers that are more than one router away you still need to apply the 'ebgp-multihop' command on the 2 peer routers but you also need to make sure you have routes for the loopback interfaces of the eBGP peers on the intermedaite routers, otherwise you will end up with a 'black hole' and packets being dropped as there is no vaild route to the peers.
Wednesday, July 14, 2010
CCNP - ENTERPRISE - Advertise a summary route in to BGP
Before BGP advertises a route it must be able to find it in the routing table.
This presents a problem when it comes to advertising a summary route as the summary you wish advertise will not be acutally listed in the routing table. Your subnets will be but the summary route wouldn't be.
To get round this you first configure a static route for your summary route which in turn is added to the routing table:
R1(config)#ip route 192.168.0.0 255.255.0.0 NULL0
This adds a static route pointing to NULL0 in to your routing table. Remember you will have more specific routes to the subnets you are wanting to summarise, such as 192.168.10.0/24, 192.168.20.0/24 and so on. As the routing look up works on 'Longest Match' this NULL0 static route is ok as you will/should always match the subnet with in the summary static route you applied.
With the summary route now installed in the routing table you can go ahead and advertise the summary in to BGP:
R1(config)#router bgp 500
R1(config-router)#network 192.168.0.0 mask 255.255.0.0
!
Here, you are advertising the class C /24 subnets as a /16 summary route. As there is a route in the routing table for this entry BGP will advertise it.
This presents a problem when it comes to advertising a summary route as the summary you wish advertise will not be acutally listed in the routing table. Your subnets will be but the summary route wouldn't be.
To get round this you first configure a static route for your summary route which in turn is added to the routing table:
R1(config)#ip route 192.168.0.0 255.255.0.0 NULL0
This adds a static route pointing to NULL0 in to your routing table. Remember you will have more specific routes to the subnets you are wanting to summarise, such as 192.168.10.0/24, 192.168.20.0/24 and so on. As the routing look up works on 'Longest Match' this NULL0 static route is ok as you will/should always match the subnet with in the summary static route you applied.
With the summary route now installed in the routing table you can go ahead and advertise the summary in to BGP:
R1(config)#router bgp 500
R1(config-router)#network 192.168.0.0 mask 255.255.0.0
!
Here, you are advertising the class C /24 subnets as a /16 summary route. As there is a route in the routing table for this entry BGP will advertise it.
CCNP - ENTERPRISE - Configure Local Preference
Local Prefence is used by iBGP peers to determine the Best Path out of the AS for a given route.
Set to 100 by default, the highest Local Preference wins.
You can either set the Local Preference on given router or for a specific route.
For a router do:
R1(config)#router bgp 100
R1(config-router)#bgp default local-preference [value]
where [value] = a figure from 0 - 4294967295
All routes that R1 receives from an eBGP will have the local preference set to [value] when advertised to iBGP neighbors.
To set the local preference for a given route you use an ACL, define a route map matching the ACL and then setting the Local Preference, fianlly apply the route-map to the necessary neighbor statements:
R2(config)#access-list 44 permit 10.10.10.0 0.0.0.255
!
R2(config)#route-map Local_Pref permit 10
R2(config-route-map)#match ip address 44
R2(config-route-map)#set Local_Preference 300
!
R2(config)#route-map Local_Pref permit 20
!
R2(config)#router bgp 200
R2(config-router)#neighbor 192.168.200.1 remote-map Local_Pref in
!
In the example above, route-map Local_Pref is configure to match networks permitted in ACL 44.
The route-map sets the Local Preference to 300 for the 10.10.10.0/24 networks. The second statement (permit 20) catches all other networks not covered in the (Permit 10) statement and as there are no match/set parameters these routes are processed as usual.
The route map is assigned to Neighbor 192.168.200.1 inbound. When R2 receives updates from 192.168.200.1 it assigns the local preference routes to 10.10.10.0/24.
Use #sh ip bgp to verify this.
If you have other routers with paths to 10.10.10.0/24 but you want to use R2 specifically for this route you define your route-map as above but set the Local Preference to one BELOW that of R2 - Remember HIGHEST LOCAL PREFERENCE WINS!
As a result when the route to 10.10.10.0/24 is advertised to other iBGP peers they select the path to R2 as the Best Path.
Set to 100 by default, the highest Local Preference wins.
You can either set the Local Preference on given router or for a specific route.
For a router do:
R1(config)#router bgp 100
R1(config-router)#bgp default local-preference [value]
where [value] = a figure from 0 - 4294967295
All routes that R1 receives from an eBGP will have the local preference set to [value] when advertised to iBGP neighbors.
To set the local preference for a given route you use an ACL, define a route map matching the ACL and then setting the Local Preference, fianlly apply the route-map to the necessary neighbor statements:
R2(config)#access-list 44 permit 10.10.10.0 0.0.0.255
!
R2(config)#route-map Local_Pref permit 10
R2(config-route-map)#match ip address 44
R2(config-route-map)#set Local_Preference 300
!
R2(config)#route-map Local_Pref permit 20
!
R2(config)#router bgp 200
R2(config-router)#neighbor 192.168.200.1 remote-map Local_Pref in
!
In the example above, route-map Local_Pref is configure to match networks permitted in ACL 44.
The route-map sets the Local Preference to 300 for the 10.10.10.0/24 networks. The second statement (permit 20) catches all other networks not covered in the (Permit 10) statement and as there are no match/set parameters these routes are processed as usual.
The route map is assigned to Neighbor 192.168.200.1 inbound. When R2 receives updates from 192.168.200.1 it assigns the local preference routes to 10.10.10.0/24.
Use #sh ip bgp to verify this.
If you have other routers with paths to 10.10.10.0/24 but you want to use R2 specifically for this route you define your route-map as above but set the Local Preference to one BELOW that of R2 - Remember HIGHEST LOCAL PREFERENCE WINS!
As a result when the route to 10.10.10.0/24 is advertised to other iBGP peers they select the path to R2 as the Best Path.
CCNP - ENTERPRISE - Configure the MED or BGP Metric
The MED is used between eBGP neighbors and is the only means you have to try and influence how a remote AS views your routes.
To influence how a remote AS selects the best path for your given network you define an ACL to permit the routes you wish to influence, next you confiigure a route-map which matches the ACL then set the Metric to your value (remember lowest wins) finally you apply the route-map to your neighbour statement under the BGP process.
e.g.)
R1(config)#access-list 10 permit 192.168.10.0 255.255.255.0
!
R1(config)#route-map MED_OUTBOUND permit 10
R1(config-route-map)#match ip address 10
R1(config-route-map)#set Metric 100
!
R1(config)#route-map MED_OUTBOUND permit 20
R1(config-route-map)#set Metric 200
!
R1(config)#router bgp 500
R1(config-router)#neighbor 10.1.1.1 route-map MED_OUTBOUND out*
* route-map applies outbound to the routes you are advertising in BGP that match the ACL you configured.
In the example above routes for 192.168.10.0 advertised to BGP neighbor 10.1.1.1 will have a MED or Metric of 100. The default for MED is '0'
The next line (permit 20) states that 'All other routes' will have a Metric of 200. Remember Lowest Metric wins so by setting 'All other routes' to have a MED of 200 you are trying to influence the remote AS to use an different router (say R2) for 'All other routes'.
To ensure you influence the remote AS to direct traffic for 192.168.10.0 to R1 set the MED for 192.168.10.0 on R2 (plus any other routers that have a vaild path to 192.168.10.0) to a figure greater than that set on R1. Also for 'All other routes' set the MED to below that of the R1 catch all statement.
Keep in mind that MED or Metric is meets criteria 6 in the list of match statements for BGP path selection. If your route matches any of the preceeding criterion for Best Path selection then MED will not influence how the remote AS views the route you are advertising.
To influence how a remote AS selects the best path for your given network you define an ACL to permit the routes you wish to influence, next you confiigure a route-map which matches the ACL then set the Metric to your value (remember lowest wins) finally you apply the route-map to your neighbour statement under the BGP process.
e.g.)
R1(config)#access-list 10 permit 192.168.10.0 255.255.255.0
!
R1(config)#route-map MED_OUTBOUND permit 10
R1(config-route-map)#match ip address 10
R1(config-route-map)#set Metric 100
!
R1(config)#route-map MED_OUTBOUND permit 20
R1(config-route-map)#set Metric 200
!
R1(config)#router bgp 500
R1(config-router)#neighbor 10.1.1.1 route-map MED_OUTBOUND out*
* route-map applies outbound to the routes you are advertising in BGP that match the ACL you configured.
In the example above routes for 192.168.10.0 advertised to BGP neighbor 10.1.1.1 will have a MED or Metric of 100. The default for MED is '0'
The next line (permit 20) states that 'All other routes' will have a Metric of 200. Remember Lowest Metric wins so by setting 'All other routes' to have a MED of 200 you are trying to influence the remote AS to use an different router (say R2) for 'All other routes'.
To ensure you influence the remote AS to direct traffic for 192.168.10.0 to R1 set the MED for 192.168.10.0 on R2 (plus any other routers that have a vaild path to 192.168.10.0) to a figure greater than that set on R1. Also for 'All other routes' set the MED to below that of the R1 catch all statement.
Keep in mind that MED or Metric is meets criteria 6 in the list of match statements for BGP path selection. If your route matches any of the preceeding criterion for Best Path selection then MED will not influence how the remote AS views the route you are advertising.
CCNP - ENTERPRISE - BGP Path Selection Criteria
The following is a list of criteria that BGP uses in order to select 'Best Path'.
Remember that BGP does not perform load balancing. It selects which path is best and then enters that in to the routing table (assuming there isn't an IGP with a better Administrative Distance that has the same route).
The best path is firstly one that is free of loops (AS PATH does not have the same AS listed twice - if it does it must be a loop and the path is discarded). Next there must be a valid next hop, i.e. the router must be able to reach the next hop device. As such there will be a route in the routing table be it connected, a static, dynamically applied via an IGP. Once these 2 points are met then the following factors influence path selection. First match wins and the process stops.
1) Prefer Highest Weight - Cisco proprietary, locally significant, if another router receives the weight flag it is simply ignored.
2) Prefer Highest Local Preference - influences routes in bound to the AS. Use a route-map to set the Local preference (highest wins) then apply it to the nei statement for the routes you which to influence.
3) Prefer routes originated by the local router - these are the routes listed with 0.0.0.0 in the Origin field in #sh ip bgp summary
4) Prefer Shortest AS_Path - least number of hops wins, just like a distance vector routing protocol
5) Prefer lowest Origin Code - where the route originated from be it an IGP > EGP > ? or incomplete which usually indicates the route was received via reoute redistribution from another protocol such as EIGRP.
6) Prefer the Lowest MED - this is effectively the BGP metric and influences how remote AS's view the path of the routes you advertise.
Remember that BGP does not perform load balancing. It selects which path is best and then enters that in to the routing table (assuming there isn't an IGP with a better Administrative Distance that has the same route).
The best path is firstly one that is free of loops (AS PATH does not have the same AS listed twice - if it does it must be a loop and the path is discarded). Next there must be a valid next hop, i.e. the router must be able to reach the next hop device. As such there will be a route in the routing table be it connected, a static, dynamically applied via an IGP. Once these 2 points are met then the following factors influence path selection. First match wins and the process stops.
1) Prefer Highest Weight - Cisco proprietary, locally significant, if another router receives the weight flag it is simply ignored.
2) Prefer Highest Local Preference - influences routes in bound to the AS. Use a route-map to set the Local preference (highest wins) then apply it to the nei statement for the routes you which to influence.
3) Prefer routes originated by the local router - these are the routes listed with 0.0.0.0 in the Origin field in #sh ip bgp summary
4) Prefer Shortest AS_Path - least number of hops wins, just like a distance vector routing protocol
5) Prefer lowest Origin Code - where the route originated from be it an IGP > EGP > ? or incomplete which usually indicates the route was received via reoute redistribution from another protocol such as EIGRP.
6) Prefer the Lowest MED - this is effectively the BGP metric and influences how remote AS's view the path of the routes you advertise.
Subscribe to:
Posts (Atom)