Wednesday, August 5, 2009

Cisco official Podcast Series

We are here in 2009 and moving into 2010 next year. There are a lot ways we can learning new stuff. Now cisco new Technology Podcasts let you can learn new stuff from website and you also can download it to you Apple series Ipod, Iphone. Take a look.


http://www.cisco.com/en/US/products/products_technology_podcast_listing.html

Monday, June 15, 2009

Dual OSPF process in IOS

I try yo move some different VPN into different path for reduce link utilization reach 95% and packet lost. In my topology, I add lower links between POPs. For the IGP cost which will not have traffic on it. Another one is the next-hop is the same from the same PE. The IOS open a option for you, "bgp next-hop loopback" under vrf config mode. After I change the next-hop, I move to IGP question. In my idea I wanna try to add another IGP domain against the originate. The new lower link will in the new IGP domain and redistributing into the originate IGP. Both are using OSPF. This call "OSPF Redistribution Among Different OSPF Processes" Ref links:

OSPF Redistribution Among Different OSPF Processes
http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080531fd2.shtml

Suboptimal Routing When Redistributing Between OSPF Processes
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00801069aa.shtml

For simple topology :

R1----Fe----R2

﹨___Seri___/

R1 access R2 via 2 type interface "FastEthernet and Serial" Both R1, R2 create 2 Loopback interface. Each interface inside one OSPF domain. And two Redistribution Points(both R1,R2)

The key point is here:

OSPF does not do any OSPF route selection between processes

(for instance, OSPF metrics and route types are not taken into account,

when deciding the route of which process should be installed into the routing table).

The OSPF route selection rule is that intra-area routes are preferred over inter-area routes,

which are preferred over external routes. However,

this rule should apply to routes learned via the same process. In other words,

there is no preference between external routes from one process compared to internal routes of other process.

The preference rule between a given OSPF process and any other process

After redistribution, R1 will see the Loopback interface from R2 via the ower OSPF PID. The way to fix it is "distance" under router config mode. When dual or multiple OSPF running in the same box it's like different protocol (OSPF vs EIGRP). You have to change the external AD in each IGP domain if redistribution between each other. Or the Suboptimal Routing will in your network.

Friday, April 24, 2009

resolve-vpn in Junos

In the MPLS VPN network, There are different between IOS and Junos. There we are talk about the label in each OS.

In IOS, the label can be allocate from LDP/TDP(IGP), or the BGP (ipv4 or vpnv4). This is very important for Inter-AS or CSC which will swap label at border ASBR. if the label can't match the data plane is lost end to end connection.

In the Junos, It's a little complex where in inet.0 or inet.3. First we remind what's the inet.0 and inet.3. For the inet.0, in the JNCIA ebook it's is the table used to store IPv4 unicast routes(OSPF, RIP. ISIS) For the inet.3 table it contains the egress IP address of a MPLS label switched path (LSP).

In the IOS BGP table, if the next-hop is un-reachable it will not forward to the peer, as the same as ipv4 and vpnv4. How about in the vpnv4, if the next-hop not reach via mpls label ?? Well, the answer is BGP routing is work for you but the data plane isn't work. Because the packet will drop at PE router while there is no label to reach remote PE.

For the Junos, It's more technical then IOS. The rule is "If the next-hop in bgp.l3vpn.0 can reach via inet.3. It will not forward to peer" It's simple if I can't reach the peer via a MPLS label I'll not update the BGP route to perr. No black hole in the path.

So, The resolve-vpn command help you to install BGP route update with the label into the inet.3 table. In the Inter-AS and CSC the bgp update will have a label inside the update. And Junos will put BGP label into inet.3 and the BGP update can send to peer.

That's the resolve-vpnwork for you.

Monday, April 13, 2009

Cisco 224.0.0.x flood

In general, We know 2 routers in the same segment with OSPF or EIGRP, they will bcome neighbor. But how about the Layer 2 device, How does it know which port is join the EIGRP multicast group 224.0.0.10??

There is a doc in cisco.com about how switch process the reserved, destination, multicast IP addresses. It's Source-Only Networks.

Source-Only Networks

In a source-only network, switch ports are connected to multicast source ports and multicast router ports. The switch ports are not connected to hosts that send IGMP join or leave messages.

The switch learns about IP multicast groups that alias with reserved, destination, multicast IP addresses (224.0.0.x) from the IP multicast data stream by using the source-only learning method. The switch forwards traffic that aliases with these multicast addresses only to the multicast router ports.

The default learning method for traffic that aliases with reserved, destination, multicast IP addresses is IP multicast-source-only learning.Traffic that does not alias with these multicast addresses is forwarded to both the multicast source ports and multicast router ports. You cannot disable IP multicast-source-only learning for the traffic with reserved, destination, multicast IP addresses.

By default, the switch ages out forwarding-table entries that were learned by the source-only learning method and that are not in use. If the aging time is too long or is disabled, the forwarding table is filled with unused entries that the switch learned by using source-only learning or by using the IGMP join messages. When the switch receives traffic for new IP multicast groups, it floods the packet to all ports in the same VLAN. This unnecessary flooding can impact switch performance.

If aging is disabled and you want to delete multicast addresses that the switch learned by using source-only learning, re-enable aging of the forwarding-table entries. The switch can now age out the multicast addresses that were learned by the source-only learning method and are not in use.

Sunday, April 5, 2009

JNCIP part 6

The tricky JNCIP ibgp requirement :

  • You must configure at least three clusters and at least two route reflectors.

  • You must use physical address peering in at least one of your clusters.

  • The failure of any link must not break the route reflection topology.

  • The route reflection topology must not impose suboptimal routing or black holes.

  • Authentication and logging settings from the previous section must remain in effect.

The ebook indicate the r3, r4 will in different cluster because :

But placing both r3 and r4 in the same cluster would be a mistake in this case,

because doing so will cause r3 and r4 to ignore updates that carry their common cluster ID.

This will result in missing routes on one of the reflectors should a peering interface fail on

one of the two route reflectors that serve clients r1 or r2,

which would violate the redundancy aspects of your design requirements.


I'll show you why.

If both R3 and R4 in the same cluster 1.1.1.1 and R2 to R4 interface is down.
R4 BGP peering to r2 and r1 is gone, and both r1,r2 send BGP update to r3, then r3 will update to r4. When R4 received BGP update from R3, R4 will not accept "because r3,r4 in the same cluster"


A Destination P Prf Metric 1 Metric 2 Next hop AS path
* 192.168.50.0/24 B 170 100 >10.0.2.9 I

iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

R4 will get missing route. This result will make you score 0 point.

Half point cause rain

The 2 round of the 2009 F1 GP was stop at after 32 laps, The heavy rainning made the race stop. Brawn GP's Jenson Button won the race in first and second round. A special score report by dirver is half from regular. (10-8-7-6-5-4-3-2-1) to (5-4-3.5-3-2.5-2-0.5). In the driver standing, Button leading Barrichello 5 points.

Tuesday, March 31, 2009

JNCIP part 5

JNCIP part 5

The JNCIP iBGP case study, we will look at each requirement:

  • Redistribute the static routes shown earlier in Figure 5.7 into IBGP, and using communities, ensure that all routers prefer r2's 192.168.100/24 IBGP route. You must not alter the default local preference of this route

Both R1,R2 will adv 192.168.100/24 to bgp peer, and R2 as primary with change Local-P. First at all, how many BGP attribute we can used ?

1, No weight here, it's Junos not IOS. forget it.
2, No Local-P, The requirement said can't change Local-P.
3, as-path, The iBGP update will not change as-path.
4, Origin code, The JNCIP ebook didn't using this way, but I DO.

policy-statement ibgp-exp {
term 1 {
from protocol static;
then {
metric 111;
origin incomplete;
accept;
}
}
}

Both R3,R4 will not select R1 as best route for 192.168.100/24
R3
192.168.100.0/24 *[BGP/170] 00:00:10, localpref 100
AS path: I
> to 10.0.4.2 via fe-0/1/0.23
[BGP/170] 00:00:10, localpref 100, from 10.0.3.4
AS path: I
> to 10.0.4.2 via fe-0/1/0.23
[BGP/170] 02:59:50, MED 111, localpref 100
AS path: ?
> to 10.0.4.14 via fe-0/1/2.13

so, It work for me!