this guy's got some shit...drive fast, take chances...
http://mrconfigure.blogspot.com/2008/08/about-me.html
network cisco ccna gns3 certification arteq
a network runs through it
Monday, October 29, 2012
bgp: static on steroids?
not exactly... it's a dynamic routing protocol that's not dynamic, that's all... you have to do everything...
3 routers, 3 as's, ebgp...
first establish an igp; how about ospf ?
ospf is a decent choice...
r1#sh ip route ospf
Gateway of last resort is not set
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/2] via 10.1.1.2, 00:06:15, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/3] via 10.1.1.2, 00:06:15, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O 10.1.1.4/30 [110/2] via 10.1.1.2, 00:06:15, FastEthernet0/0
bgp is not lit up yet, but we know r3 is reachable by r1 because the routing table says so...
r1#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/13/32 ms
r1#debug ip tcp trans
TCP special event debugging is on
r1#
establishing a tcp connection is vital...word has it ebgp is usually set up with loopbacks, that makes sense to me... but we don't want to use a static route since we want bgp to do at least some of the work... when we set up the first neighbor we go into the listen state...
r1(config)#router bgp 100
r1(config-router)#neighbor 2.2.2.2 remote-as 200
r1(config-router)#
*Oct 29 18:08:38: TCB67A81330 created
*Oct 29 18:08:38: TCB67A81330 setting property TCP_PMTU (10) 674C8BE4
*Oct 29 18:08:38: TCB67A81330 setting property TCP_TOS (1) 674C8BF0
*Oct 29 18:08:38: TCB67A81330 setting property TCP_VRFTABLEID (14) 67A80FB8
*Oct 29 18:08:38: TCB67A81330 setting property TCP_IN_TTL (27) 674C8BC8
*Oct 29 18:08:38: TCB67A81330 setting property TCP_OUT_TTL (28) 674C8BC8
*Oct 29 18:08:38: TCB67A81330 setting property TCP_OUT_TTL (28) 67A811D6
*Oct 29 18:08:38: TCB67A81330 bound to 0.0.0.0.179
*Oct 29 18:08:38: TCB67A81330 setting property TCP_ACCESS_CHECK (5) 602F59E0
*Oct 29 18:08:38: TCB67A81330 setting property TCP_MD5KEY (2) 0
r1(config-router)#
*Oct 29 18:08:38: TPA: Reserved port 179 in Transport Port Agent for TCP IP type 1
*Oct 29 18:08:38: TCB67A81330 listening with queue 1
we want the update source to be the loopbacks all the way around, and because it's ebgp, we have to use the ebgp multihop statement...
r1(config-router)#neighbor 2.2.2.2 update-sour lo0
r1(config-router)#neighbor 2.2.2.2 ebgp-multihop 3
when we perform this on r1, tcp simply complains in the debugs, as expected...
we need to get r2 in the game...
just adding the neighbor remote statement doesn't get it... we need the update and the multihop also...
this is a great verification...
r2(config-router)#do sh tcp brie all
TCB Local Address Foreign Address (state)
68977010 2.2.2.2.28228 1.1.1.1.179 ESTAB
67F46CE4 0.0.0.0.179 1.1.1.1.* LISTEN
i've already configured different loopback addresses to advertise as networks not advertised already by ospf...
the last pieces of the puzzle are, setting the rest of the neighbor statements on r2 and r3, and adding the bgp only networks...
r2(config-router)#neighbor 3.3.3.3 remote-as 300
r2(config-router)#neighbor 3.3.3.3 update-s lo0
r2(config-router)#neighbor 3.3.3.3 ebgp-multi 3
r3(config-router)#neighb 2.2.2.2 remote-as 200
r3(config-router)#neighb 2.2.2.2 update-sour lo0
r3(config-router)#neighb 2.2.2.2 ebgp-multi 3
r3(config-router)#
*Oct 29 18:28:55: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
then finally, advertise the lo1 networks we created for bgp only...
r1#sh run | sec router
router ospf 1
network 1.1.1.0 0.0.0.255 area 0
network 10.1.1.0 0.0.0.3 area 0
router bgp 100
bgp log-neighbor-changes
network 192.168.1.0
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 ebgp-multihop 3
neighbor 2.2.2.2 update-source Loopback0
r1#
r2#sh ip bgp
BGP table version is 4, local router ID is 192.168.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 1.1.1.1 0 0 100 i
*> 192.168.2.0 0.0.0.0 0 32768 i
*> 192.168.3.0 3.3.3.3 0 0 300 i
beautiful... no static routes...
r1#sh ip route bgp
Gateway of last resort is not set
B 192.168.2.0/24 [20/0] via 2.2.2.2, 00:02:00
B 192.168.3.0/24 [20/0] via 2.2.2.2, 00:02:00
r3#sh ip route bgp
Gateway of last resort is not set
B 192.168.1.0/24 [20/0] via 2.2.2.2, 00:02:11
B 192.168.2.0/24 [20/0] via 2.2.2.2, 00:02:42
and b's up the ass...
r1#ping 192.168.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms
with the network statements be sure to use the mask for networks that fall outside classful boundaries, meaning vlsm... since we are using a class C address without vlsm, the mask statement is unnecessary in this case...
r2#sh run | sec bgp
router bgp 200
bgp log-neighbor-changes
network 192.168.2.0
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 ebgp-multihop 3
neighbor 1.1.1.1 update-source Loopback0
neighbor 3.3.3.3 remote-as 300
neighbor 3.3.3.3 ebgp-multihop 3
neighbor 3.3.3.3 update-source Loopback0
3 routers, 3 as's, ebgp...
first establish an igp; how about ospf ?
ospf is a decent choice...
r1#sh ip route ospf
Gateway of last resort is not set
2.0.0.0/32 is subnetted, 1 subnets
O 2.2.2.2 [110/2] via 10.1.1.2, 00:06:15, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
O 3.3.3.3 [110/3] via 10.1.1.2, 00:06:15, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O 10.1.1.4/30 [110/2] via 10.1.1.2, 00:06:15, FastEthernet0/0
bgp is not lit up yet, but we know r3 is reachable by r1 because the routing table says so...
r1#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/13/32 ms
r1#debug ip tcp trans
TCP special event debugging is on
r1#
establishing a tcp connection is vital...word has it ebgp is usually set up with loopbacks, that makes sense to me... but we don't want to use a static route since we want bgp to do at least some of the work... when we set up the first neighbor we go into the listen state...
r1(config)#router bgp 100
r1(config-router)#neighbor 2.2.2.2 remote-as 200
r1(config-router)#
*Oct 29 18:08:38: TCB67A81330 created
*Oct 29 18:08:38: TCB67A81330 setting property TCP_PMTU (10) 674C8BE4
*Oct 29 18:08:38: TCB67A81330 setting property TCP_TOS (1) 674C8BF0
*Oct 29 18:08:38: TCB67A81330 setting property TCP_VRFTABLEID (14) 67A80FB8
*Oct 29 18:08:38: TCB67A81330 setting property TCP_IN_TTL (27) 674C8BC8
*Oct 29 18:08:38: TCB67A81330 setting property TCP_OUT_TTL (28) 674C8BC8
*Oct 29 18:08:38: TCB67A81330 setting property TCP_OUT_TTL (28) 67A811D6
*Oct 29 18:08:38: TCB67A81330 bound to 0.0.0.0.179
*Oct 29 18:08:38: TCB67A81330 setting property TCP_ACCESS_CHECK (5) 602F59E0
*Oct 29 18:08:38: TCB67A81330 setting property TCP_MD5KEY (2) 0
r1(config-router)#
*Oct 29 18:08:38: TPA: Reserved port 179 in Transport Port Agent for TCP IP type 1
*Oct 29 18:08:38: TCB67A81330 listening with queue 1
we want the update source to be the loopbacks all the way around, and because it's ebgp, we have to use the ebgp multihop statement...
r1(config-router)#neighbor 2.2.2.2 update-sour lo0
r1(config-router)#neighbor 2.2.2.2 ebgp-multihop 3
when we perform this on r1, tcp simply complains in the debugs, as expected...
we need to get r2 in the game...
just adding the neighbor remote statement doesn't get it... we need the update and the multihop also...
r2(config)#router bgp 200
r2(config-router)#neighb 1.1.1.1 remote-as 100
r2(config-router)#neigh 1.1.1.1 update-s lo0
r2(config-router)#neighb 1.1.1.1 ebgp-multihop 3
r2(config-router)#
*Oct 29 18:21:03: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
r2(config-router)#neighb 1.1.1.1 remote-as 100
r2(config-router)#neigh 1.1.1.1 update-s lo0
r2(config-router)#neighb 1.1.1.1 ebgp-multihop 3
r2(config-router)#
*Oct 29 18:21:03: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
this is a great verification...
r2(config-router)#do sh tcp brie all
TCB Local Address Foreign Address (state)
68977010 2.2.2.2.28228 1.1.1.1.179 ESTAB
67F46CE4 0.0.0.0.179 1.1.1.1.* LISTEN
i've already configured different loopback addresses to advertise as networks not advertised already by ospf...
the last pieces of the puzzle are, setting the rest of the neighbor statements on r2 and r3, and adding the bgp only networks...
r2(config-router)#neighbor 3.3.3.3 remote-as 300
r2(config-router)#neighbor 3.3.3.3 update-s lo0
r2(config-router)#neighbor 3.3.3.3 ebgp-multi 3
r3(config-router)#neighb 2.2.2.2 remote-as 200
r3(config-router)#neighb 2.2.2.2 update-sour lo0
r3(config-router)#neighb 2.2.2.2 ebgp-multi 3
r3(config-router)#
*Oct 29 18:28:55: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
then finally, advertise the lo1 networks we created for bgp only...
r1#sh run | sec router
router ospf 1
network 1.1.1.0 0.0.0.255 area 0
network 10.1.1.0 0.0.0.3 area 0
router bgp 100
bgp log-neighbor-changes
network 192.168.1.0
neighbor 2.2.2.2 remote-as 200
neighbor 2.2.2.2 ebgp-multihop 3
neighbor 2.2.2.2 update-source Loopback0
r1#
r2#sh ip bgp
BGP table version is 4, local router ID is 192.168.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 1.1.1.1 0 0 100 i
*> 192.168.2.0 0.0.0.0 0 32768 i
*> 192.168.3.0 3.3.3.3 0 0 300 i
beautiful... no static routes...
r1#sh ip route bgp
Gateway of last resort is not set
B 192.168.2.0/24 [20/0] via 2.2.2.2, 00:02:00
B 192.168.3.0/24 [20/0] via 2.2.2.2, 00:02:00
r2#sh ip route bgp
Gateway of last resort is not set
B 192.168.1.0/24 [20/0] via 1.1.1.1, 00:03:16
B 192.168.3.0/24 [20/0] via 3.3.3.3, 00:03:17
Gateway of last resort is not set
B 192.168.1.0/24 [20/0] via 1.1.1.1, 00:03:16
B 192.168.3.0/24 [20/0] via 3.3.3.3, 00:03:17
Gateway of last resort is not set
B 192.168.1.0/24 [20/0] via 2.2.2.2, 00:02:11
B 192.168.2.0/24 [20/0] via 2.2.2.2, 00:02:42
and b's up the ass...
r1#ping 192.168.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 ms
with the network statements be sure to use the mask for networks that fall outside classful boundaries, meaning vlsm... since we are using a class C address without vlsm, the mask statement is unnecessary in this case...
r2#sh run | sec bgp
router bgp 200
bgp log-neighbor-changes
network 192.168.2.0
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 ebgp-multihop 3
neighbor 1.1.1.1 update-source Loopback0
neighbor 3.3.3.3 remote-as 300
neighbor 3.3.3.3 ebgp-multihop 3
neighbor 3.3.3.3 update-source Loopback0
eigrp, russ white...
this is a good definition for nbma...
...what is an NBMA network? As the name implies, an NBMA network supports access from multiple routers at the same time but doesn’t support broadcast packets. For example, frame relay multipoint networks allow a single IP subnet to be shared by multiple routers in a partial or full mesh topology. Although each router shares an IP subnet with the other routers across the frame relay cloud, they cannot send a single broadcast packet and have it simultaneously delivered to all the other routers on that subnet. Instead, the pseudobroadcast packets would need to be replicated and sent to each neighbor independently.
he should change his name to russ blonde...
and just in case:
split horizon...
The split-horizon rule states that a router should not advertise destinations out the interface it is using to reach those destinations.
also, it is important that you use the correct command to disable split horizon in eigrp, see below (i ran into this over the weekend when i was trying to see all links, show ip eigrp topo all-links, and they weren't showing up)...
you might think that the command
russ, you're a prince...
one last note here:
do not be mistaken that russ's book on eigrp is only about eigrp... on the contrary, it is about routing in general and is full of gems that will help you with any protocol, including the static protocol... that's correct, he presents the idea of default and static routes as protocols, which may be obvious, but when was the last time you thought of them that way...
...what is an NBMA network? As the name implies, an NBMA network supports access from multiple routers at the same time but doesn’t support broadcast packets. For example, frame relay multipoint networks allow a single IP subnet to be shared by multiple routers in a partial or full mesh topology. Although each router shares an IP subnet with the other routers across the frame relay cloud, they cannot send a single broadcast packet and have it simultaneously delivered to all the other routers on that subnet. Instead, the pseudobroadcast packets would need to be replicated and sent to each neighbor independently.
he should change his name to russ blonde...
and just in case:
split horizon...
The split-horizon rule states that a router should not advertise destinations out the interface it is using to reach those destinations.
also, it is important that you use the correct command to disable split horizon in eigrp, see below (i ran into this over the weekend when i was trying to see all links, show ip eigrp topo all-links, and they weren't showing up)...
you might think that the command
no ip split-horizon
configured on router A’s multipoint serial interface would change the
behavior. In fact, it doesn’t impact EIGRP operation at all! Instead,
you must use the EIGRP-specific command no ip eigrp split-horizon instead. Normally, disabling split horizon is not recommended, but occasionally, a
legitimate need for disabling the default behavior occurs.russ, you're a prince...
one last note here:
do not be mistaken that russ's book on eigrp is only about eigrp... on the contrary, it is about routing in general and is full of gems that will help you with any protocol, including the static protocol... that's correct, he presents the idea of default and static routes as protocols, which may be obvious, but when was the last time you thought of them that way...
Sunday, October 28, 2012
pbr in gns3...
i was having trouble earlier with pbr, determining path choice with a route map... thought i was losing my mind... see this:
http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qcpolicy.html
according to this document pbr is supported in cef based switching since 12.0... the question is how well is cef supported in gns3 running ios... my guess is gns3 may choke a little here... i'm the last one to call out gns3; it's the best thing that ever happened to people like us, but...
here's the example:
r1#trace 6.6.6.6
Type escape sequence to abort.
Tracing the route to 6.6.6.6
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.1.2 32 msec
10.1.2.2 20 msec
r1 has a choice of two paths in this ospf/eigrp redistributed topology to get to the far end loopback 6.6.6.6... both paths are supported in the trace... i want to determine one path...
so i set up a pbr on r1 to force the path through r2...
r1(config)#route-map this
r1(config-route-map)#match ip add 1
r1(config-route-map)#set ip next-hop 10.1.1.2
r1(config-route-map)#exit
r1(config)#int f0/0
r1(config-if)#ip policy route-map this
r1(config-if)#
r1#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/20 ms
r1#sh route-map
route-map this, permit, sequence 10
Match clauses:
ip address (access-lists): 1
Set clauses:
ip next-hop 10.1.1.2
Policy routing matches: 0 packets, 0 bytes
no matches...
turn off cef...
r1(config)#no ip cef
r1(config)#end
r1#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/13/20 ms
r1#sh route-map
route-map this, permit, sequence 10
Match clauses:
ip address (access-lists): 1
Set clauses:
ip next-hop 10.1.1.2
Policy routing matches: 0 packets, 0 bytes
still no matches... so i turned cef back on...
if i debug the policy i get no hits as well...
r1#debug ip policy
Policy routing debugging is on
r1#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/24 ms
nothing...
then there's this... ip local policy route-map (route-map name) see link above...
r1(config)#ip local policy route-map this
r1(config)#end
r1#
*Oct 28 12:34:29: %SYS-5-CONFIG_I: Configured from console by console
r1#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/13/20 ms
r1#
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6, len 100, policy match
*Oct 28 12:34:33: IP: route map this, item 10, permit
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6 (FastEthernet0/0), len 100, policy routed
*Oct 28 12:34:33: IP: local to FastEthernet0/0 10.1.1.2
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6, len 100, policy match
*Oct 28 12:34:33: IP: route map this, item 10, permit
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6 (FastEthernet0/0), len 100, policy routed
*Oct 28 12:34:33: IP: local to FastEthernet0/0 10.1.1.2
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6, len 100, policy match
*Oct 28 12:34:33: IP: route map this, item 10, permit
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6 (FastEthernet0/0), len 100, policy routed
*Oct 28 12:34:33: IP: local to FastEthernet0/0 10.1.1.2
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6, len 100, policy match
*Oct 28 12:34:33: IP: route map this, item 10, permit
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6 (FastEthernet0/0), len 100, policy routed
*Oct 28 12:34:33: IP: local to FastEthernet0/0 10.1.1.2
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6, len 100, policy match
*Oct 28 12:34:33: IP: route map this, item 10, permit
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6 (FastEthernet0/0)
r1#, len 100, policy routed
*Oct 28 12:34:33: IP: local to FastEthernet0/0 10.1.1.2
now i don't feel like i'm losing my goddamn mind...
r1#sh route-map
route-map this, permit, sequence 10
Match clauses:
ip address (access-lists): 1
Set clauses:
ip next-hop 10.1.1.2
Nexthop tracking current: 0.0.0.0
10.1.1.2, fib_nh:0,oce:0,status:0
Policy routing matches: 5 packets, 500 bytes
that's a big difference...
r1#trace 6.6.6.6
Type escape sequence to abort.
Tracing the route to 6.6.6.6
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.1.2 8 msec 4 msec 8 msec
2 192.168.1.2 8 msec 8 msec 8 msec
3 172.16.1.1 12 msec 40 msec *
no big deal... i still love gns3...
http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qcpolicy.html
according to this document pbr is supported in cef based switching since 12.0... the question is how well is cef supported in gns3 running ios... my guess is gns3 may choke a little here... i'm the last one to call out gns3; it's the best thing that ever happened to people like us, but...
here's the example:
r1#trace 6.6.6.6
Type escape sequence to abort.
Tracing the route to 6.6.6.6
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.1.2 32 msec
10.1.2.2 20 msec
r1 has a choice of two paths in this ospf/eigrp redistributed topology to get to the far end loopback 6.6.6.6... both paths are supported in the trace... i want to determine one path...
so i set up a pbr on r1 to force the path through r2...
r1(config)#access-list 1 permit 6.6.6.6
r1(config)#access-list 1 permit any
r1(config)#do sh access-list
Standard IP access list 1
10 permit 6.6.6.6
20 permit any
r1(config)#access-list 1 permit any
r1(config)#do sh access-list
Standard IP access list 1
10 permit 6.6.6.6
20 permit any
r1(config-route-map)#match ip add 1
r1(config-route-map)#set ip next-hop 10.1.1.2
r1(config-route-map)#exit
r1(config)#int f0/0
r1(config-if)#ip policy route-map this
r1(config-if)#
r1#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/20 ms
r1#sh route-map
route-map this, permit, sequence 10
Match clauses:
ip address (access-lists): 1
Set clauses:
ip next-hop 10.1.1.2
Policy routing matches: 0 packets, 0 bytes
no matches...
turn off cef...
r1(config)#no ip cef
r1(config)#end
r1#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/13/20 ms
r1#sh route-map
route-map this, permit, sequence 10
Match clauses:
ip address (access-lists): 1
Set clauses:
ip next-hop 10.1.1.2
Policy routing matches: 0 packets, 0 bytes
still no matches... so i turned cef back on...
if i debug the policy i get no hits as well...
r1#debug ip policy
Policy routing debugging is on
r1#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/24 ms
nothing...
then there's this... ip local policy route-map (route-map name) see link above...
r1(config)#ip local policy route-map this
r1(config)#end
r1#
*Oct 28 12:34:29: %SYS-5-CONFIG_I: Configured from console by console
r1#ping 6.6.6.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/13/20 ms
r1#
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6, len 100, policy match
*Oct 28 12:34:33: IP: route map this, item 10, permit
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6 (FastEthernet0/0), len 100, policy routed
*Oct 28 12:34:33: IP: local to FastEthernet0/0 10.1.1.2
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6, len 100, policy match
*Oct 28 12:34:33: IP: route map this, item 10, permit
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6 (FastEthernet0/0), len 100, policy routed
*Oct 28 12:34:33: IP: local to FastEthernet0/0 10.1.1.2
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6, len 100, policy match
*Oct 28 12:34:33: IP: route map this, item 10, permit
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6 (FastEthernet0/0), len 100, policy routed
*Oct 28 12:34:33: IP: local to FastEthernet0/0 10.1.1.2
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6, len 100, policy match
*Oct 28 12:34:33: IP: route map this, item 10, permit
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6 (FastEthernet0/0), len 100, policy routed
*Oct 28 12:34:33: IP: local to FastEthernet0/0 10.1.1.2
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6, len 100, policy match
*Oct 28 12:34:33: IP: route map this, item 10, permit
*Oct 28 12:34:33: IP: s=10.1.2.1 (local), d=6.6.6.6 (FastEthernet0/0)
r1#, len 100, policy routed
*Oct 28 12:34:33: IP: local to FastEthernet0/0 10.1.1.2
now i don't feel like i'm losing my goddamn mind...
r1#sh route-map
route-map this, permit, sequence 10
Match clauses:
ip address (access-lists): 1
Set clauses:
ip next-hop 10.1.1.2
Nexthop tracking current: 0.0.0.0
10.1.1.2, fib_nh:0,oce:0,status:0
Policy routing matches: 5 packets, 500 bytes
that's a big difference...
r1#trace 6.6.6.6
Type escape sequence to abort.
Tracing the route to 6.6.6.6
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.1.2 8 msec 4 msec 8 msec
2 192.168.1.2 8 msec 8 msec 8 msec
3 172.16.1.1 12 msec 40 msec *
no big deal... i still love gns3...
recursive lookup...
The concept of performing a lookup for the next-hop IP address toward a destination is called a recursive lookup. Recursive routes are routes that require the forwarding and adjacency information of another route. A recursive
FIB entry is used when the router must look up the next-hop IP address of a prefix referenced to find the corresponding Layer 2 header rewrite string and output interface for the destination prefix. Border Gateway Protocol (BGP) is the most common source of recursive entries, because the IP addresses used as the next hop for advertised prefixes are almost never directly connected to the router.
according to russ white, in his CEF volume...
FIB entry is used when the router must look up the next-hop IP address of a prefix referenced to find the corresponding Layer 2 header rewrite string and output interface for the destination prefix. Border Gateway Protocol (BGP) is the most common source of recursive entries, because the IP addresses used as the next hop for advertised prefixes are almost never directly connected to the router.
according to russ white, in his CEF volume...
ios v junos... memory...
most cisco ios flavors use a flat memory space which means that the current processes have access to all allocated memory at any given time... this allows for a loose and fast process allocation per requesting process...
junos, conversely, uses protected memory resources which means that specific memory is reserved for use by specific processes at any given time...
the argument can be made for advantages in both models; the flat memory model is arguably faster while the protected memory model disallows process corruption vis a vis, one process cannot subsume the others memory area; it is protected...
ios is non preemptive multitasking which means that the process gives back the resources when the process decides to, with some limits...
in ios, a process can be in one of 5 self-evident states, determined by the scheduler...
New— The process has just been created and has no resources. It has never been scheduled to run.
Ready— The process is ready to run and should be scheduled on the processor the next time it is eligible.
Run— The process is currently running.
Idle— The process is waiting for some event to become ready to run.
Dead— The process is dead; it is being cleaned up.
junos, conversely, uses protected memory resources which means that specific memory is reserved for use by specific processes at any given time...
the argument can be made for advantages in both models; the flat memory model is arguably faster while the protected memory model disallows process corruption vis a vis, one process cannot subsume the others memory area; it is protected...
ios is non preemptive multitasking which means that the process gives back the resources when the process decides to, with some limits...
in ios, a process can be in one of 5 self-evident states, determined by the scheduler...
New— The process has just been created and has no resources. It has never been scheduled to run.
Ready— The process is ready to run and should be scheduled on the processor the next time it is eligible.
Run— The process is currently running.
Idle— The process is waiting for some event to become ready to run.
Dead— The process is dead; it is being cleaned up.
routing and mls... quote of the day...
changing lanes a little this morning...
i've said this in the past, and it always gets reiterated in the present, and i never get tired of seeing it in print that is not my own, especially someone as eminently qualified as russ white, in his slim book, CEF...
Layer 3 (mls) switching is routing, as far as hosts connected to the network are concerned; there is no functional difference between Layer 3 switching and routing.
thanks russ...
the switch is a router... but don't believe me, believe russ...
another point; there is so little out there about CEF, and it is one of my favorite subjects... in fact the old book Lan Switching has about two point 6 pages devoted to it, and the book is about 1000 pages total... of course that book is a waste of time as it is CatOs based... amazing there is so little out there about switching overall when switching comprises the majority of networking...
i've said this in the past, and it always gets reiterated in the present, and i never get tired of seeing it in print that is not my own, especially someone as eminently qualified as russ white, in his slim book, CEF...
Layer 3 (mls) switching is routing, as far as hosts connected to the network are concerned; there is no functional difference between Layer 3 switching and routing.
thanks russ...
the switch is a router... but don't believe me, believe russ...
another point; there is so little out there about CEF, and it is one of my favorite subjects... in fact the old book Lan Switching has about two point 6 pages devoted to it, and the book is about 1000 pages total... of course that book is a waste of time as it is CatOs based... amazing there is so little out there about switching overall when switching comprises the majority of networking...
Saturday, October 27, 2012
eigrp network and interface...
in more recent versions of ios code, the routing process can be configured directly on the interface... we know for ipv6 that is the only way... isis was always configured thus, juniper interfaces as well, so this is not a new concept...
...back to the network statement and russ brings up a fine distinction here:
the
basically using wildcard masks (instead of simply classful networks) allows you to pick and choose the interfaces to run eigrp on, whether singly, or in ranges...
using a distribute list we can pick and choose the routes we want advertised from anywhere in the eigrp network... note network 1.1.3.0 below:
r2#sh ip route eigrp
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 3 subnets
D 1.1.1.0 [90/2297856] via 172.16.1.1, 02:36:29, Serial2/0
D 1.1.2.0 [90/2297856] via 172.16.1.1, 02:36:29, Serial2/0
D 1.1.3.0 [90/2297856] via 172.16.1.1, 00:00:09, Serial2/0
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/2297856] via 192.168.1.3, 02:36:29, Serial2/1
10.0.0.0/24 is subnetted, 1 subnets
D 10.1.1.0 [90/2172416] via 192.168.1.3, 02:36:29, Serial2/1
[90/2172416] via 172.16.1.1, 02:36:29, Serial2/0
note below how fast eigrp is... as soon as you deny, wham... and then permit, and then the distribute list...
r2#sh ip route eigrp
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 2 subnets
D 1.1.1.0 [90/2297856] via 172.16.1.1, 00:00:48, Serial2/0
D 1.1.2.0 [90/2297856] via 172.16.1.1, 00:00:48, Serial2/0
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/2297856] via 192.168.1.3, 00:00:48, Serial2/1
10.0.0.0/24 is subnetted, 1 subnets
D 10.1.1.0 [90/2172416] via 192.168.1.3, 00:00:48, Serial2/1
[90/2172416] via 172.16.1.1, 00:00:48, Serial2/0
r2#
all gone...
you can also block per interface in the eigrp process with:
distribute-list 1 out s2/0
but be careful with this one, if there's an alternate route... look at the path and the rd closely for 1.1.3.0 and compare it to above...
r2#sh ip route eigrp
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 3 subnets
D 1.1.1.0 [90/2297856] via 172.16.1.1, 00:09:06, Serial2/0
D 1.1.2.0 [90/2297856] via 172.16.1.1, 00:09:06, Serial2/0
D 1.1.3.0 [90/2300416] via 192.168.1.3, 00:00:16, Serial2/1
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/2297856] via 192.168.1.3, 00:09:06, Serial2/1
10.0.0.0/24 is subnetted, 1 subnets
D 10.1.1.0 [90/2172416] via 192.168.1.3, 00:09:06, Serial2/1
[90/2172416] via 172.16.1.1, 00:09:06, Serial2/0
it took the long way around...
...back to the network statement and russ brings up a fine distinction here:
the
network command doesn’t determine what the router will advertise. Instead, the network command determines which interfaces EIGRP will run on...basically using wildcard masks (instead of simply classful networks) allows you to pick and choose the interfaces to run eigrp on, whether singly, or in ranges...
using a distribute list we can pick and choose the routes we want advertised from anywhere in the eigrp network... note network 1.1.3.0 below:
r2#sh ip route eigrp
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 3 subnets
D 1.1.1.0 [90/2297856] via 172.16.1.1, 02:36:29, Serial2/0
D 1.1.2.0 [90/2297856] via 172.16.1.1, 02:36:29, Serial2/0
D 1.1.3.0 [90/2297856] via 172.16.1.1, 00:00:09, Serial2/0
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/2297856] via 192.168.1.3, 02:36:29, Serial2/1
10.0.0.0/24 is subnetted, 1 subnets
D 10.1.1.0 [90/2172416] via 192.168.1.3, 02:36:29, Serial2/1
[90/2172416] via 172.16.1.1, 02:36:29, Serial2/0
note below how fast eigrp is... as soon as you deny, wham... and then permit, and then the distribute list...
r1(config)#access-list 1 deny 1.1.3.0 0.0.0.255
r1(config)#ac
*Oct 27 16:49:14: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.16.1.2 (Serial2/0) is resync: route configuration changed
*Oct 27 16:49:14: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.3 (FastEthernet0/0) is resync: route configuration changed
r1(config)#access-list 1 permit any
r1(config)#router eigrp 1
r1(config-router)#distrib
*Oct 27 16:49:41: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.16.1.2 (Serial2/0) is resync: route configuration changed
*Oct 27 16:49:41: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.3 (FastEthernet0/0) is resync: route configuration changed
r1(config-router)#distribute-list 1 out
r1(config-router)#
*Oct 27 16:49:59: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.16.1.2 (Serial2/0) is resync: route configuration changed
*Oct 27 16:49:59: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.3 (FastEthernet0/0) is resync: route configuration changed
r1(config-router)#
r1(config)#ac
*Oct 27 16:49:14: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.16.1.2 (Serial2/0) is resync: route configuration changed
*Oct 27 16:49:14: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.3 (FastEthernet0/0) is resync: route configuration changed
r1(config)#access-list 1 permit any
r1(config)#router eigrp 1
r1(config-router)#distrib
*Oct 27 16:49:41: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.16.1.2 (Serial2/0) is resync: route configuration changed
*Oct 27 16:49:41: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.3 (FastEthernet0/0) is resync: route configuration changed
r1(config-router)#distribute-list 1 out
r1(config-router)#
*Oct 27 16:49:59: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.16.1.2 (Serial2/0) is resync: route configuration changed
*Oct 27 16:49:59: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.3 (FastEthernet0/0) is resync: route configuration changed
r1(config-router)#
r2#sh ip route eigrp
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 2 subnets
D 1.1.1.0 [90/2297856] via 172.16.1.1, 00:00:48, Serial2/0
D 1.1.2.0 [90/2297856] via 172.16.1.1, 00:00:48, Serial2/0
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/2297856] via 192.168.1.3, 00:00:48, Serial2/1
10.0.0.0/24 is subnetted, 1 subnets
D 10.1.1.0 [90/2172416] via 192.168.1.3, 00:00:48, Serial2/1
[90/2172416] via 172.16.1.1, 00:00:48, Serial2/0
r2#
all gone...
you can also block per interface in the eigrp process with:
distribute-list 1 out s2/0
but be careful with this one, if there's an alternate route... look at the path and the rd closely for 1.1.3.0 and compare it to above...
r2#sh ip route eigrp
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 3 subnets
D 1.1.1.0 [90/2297856] via 172.16.1.1, 00:09:06, Serial2/0
D 1.1.2.0 [90/2297856] via 172.16.1.1, 00:09:06, Serial2/0
D 1.1.3.0 [90/2300416] via 192.168.1.3, 00:00:16, Serial2/1
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/2297856] via 192.168.1.3, 00:09:06, Serial2/1
10.0.0.0/24 is subnetted, 1 subnets
D 10.1.1.0 [90/2172416] via 192.168.1.3, 00:09:06, Serial2/1
[90/2172416] via 172.16.1.1, 00:09:06, Serial2/0
it took the long way around...
eigrp's factor of 256...
it is often written that eigrp is an improvement over igrp by a factor of 256...
hence, multiplying by 256... russ white:
remember that EIGRP uses the IGRP metric as its reference point and that IGRP uses a 24-bit number—224 is its maximum metric—to represent the distance to a destination. EIGRP’s designers wanted to use 32 bits to add granularity to the metric. The simplest way to use the 32 bits was to shift the existing IGRP metric left by 8 bits, which is equivalent to multiplying it by 256.
mtu, load and reliability, when configured cannot trigger an update and are therefore not useful in the calculation... on the contrary, retooling bandwidth and/or delay will trigger an update
you've seen what follows many different ways... this is arguably best in show...
take it away, russ:
wow...
hence, multiplying by 256... russ white:
remember that EIGRP uses the IGRP metric as its reference point and that IGRP uses a 24-bit number—224 is its maximum metric—to represent the distance to a destination. EIGRP’s designers wanted to use 32 bits to add granularity to the metric. The simplest way to use the 32 bits was to shift the existing IGRP metric left by 8 bits, which is equivalent to multiplying it by 256.
mtu, load and reliability, when configured cannot trigger an update and are therefore not useful in the calculation... on the contrary, retooling bandwidth and/or delay will trigger an update
you've seen what follows many different ways... this is arguably best in show...
take it away, russ:
The first thing to do when figuring out which path A will choose is to see what metric A will calculate for each path.
• The path through B will be ((107 / 10,000) + 100 + 100 + 100)256, which is 332,800.
• The path through D will be ((107 / 10,000) + 200 + 100 + 100)256, which is 358,400.
So A will choose the path through B as the best path
and will route traffic in that direction. Now, will A believe that the
path through D is loop free? Let’s calculate the RDs to see.
Figure 1.5. A simple network, using real metrics
• The RD from B will be ((107 / 10,000) + 100 + 100)256, which is 307,200.
• The RD from D will be ((107 / 10,000) + 100 + 100)256, which is 307,200.
Is the RD through D less than the FD (the metric
through the best path)? Yes, 307,200 is less than 332,800. So A will
believe that the path through D is loop free and will mark it as a
feasible successor (FS) in its topology table.
wow...
quote(s) of the day... multicast...
from russ white, eigrp for ip...
Multicast is more efficient than broadcast because the packets can be filtered by most network interface chips rather than being passed up to the IP layer to be sorted.
Updates and queries are sent as multicast packets, and the receiving router always acknowledges their receipt, using a unicast packet.
Multicast is more efficient than broadcast because the packets can be filtered by most network interface chips rather than being passed up to the IP layer to be sorted.
Updates and queries are sent as multicast packets, and the receiving router always acknowledges their receipt, using a unicast packet.
How long will a router wait before starting the recovery mechanism? Each time it sends out a multicast packet that must be reliably delivered, an EIGRP process will wait until the RTO (retransmission timeout) period has passed before beginning a recovery action. This period is calculated from the SRTT (smooth round-trip time), which is calculated as the amount of time taken in the past for each peer on an interface to respond.
sh tcp brief all...
be patient... it's bgp, or clear all... i shut down the neighbor...
r1#sh tcp brie all
TCB Local Address Foreign Address (state)
69647A48 172.16.1.1.26322 172.16.1.2.179 ESTAB
6868C0A8 0.0.0.0.179 172.16.1.2.* LISTEN
r1#
*Oct 27 07:28:48: %BGP-3-NOTIFICATION: sent to neighbor 172.16.1.2 4/0 (hold time expired) 0 bytes
r1#
*Oct 27 07:28:48: %BGP-5-NBR_RESET: Neighbor 172.16.1.2 reset (BGP Notification sent)
*Oct 27 07:28:48: %BGP-5-ADJCHANGE: neighbor 172.16.1.2 Down BGP Notification sent
*Oct 27 07:28:48: %BGP_SESSION-5-ADJCHANGE: neighbor 172.16.1.2 IPv4 Unicast topology base removed from session BGP Notification sent
r1#sh tcp brie all
TCB Local Address Foreign Address (state)
67ECC48C 172.16.1.1.14286 172.16.1.2.179 SYNSENT
6868C0A8 0.0.0.0.179 172.16.1.2.* LISTEN
r1#sh tcp brie all
TCB Local Address Foreign Address (state)
69647A48 172.16.1.1.40204 172.16.1.2.179 CLOSED
696480CC 172.16.1.1.16103 172.16.1.2.179 SYNSENT
6868C0A8 0.0.0.0.179 172.16.1.2.* LISTEN
r1#sh ip bgp summ
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 3, main routing table version 3
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.1.2 4 200 0 0 1 0 0 00:04:07 Active
r1#
then no shut the neighbor...
*Oct 27 07:34:05: %BGP-5-ADJCHANGE: neighbor 172.16.1.2 Up
r1#sh tcp brie all
TCB Local Address Foreign Address (state)
67ECC48C 172.16.1.1.179 172.16.1.2.52928 ESTAB
6868C0A8 0.0.0.0.179 172.16.1.2.* LISTEN
r1#sh ip bgp
BGP table version is 4, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 172.16.1.2 0 0 200 i
r1#sh tcp brie all
TCB Local Address Foreign Address (state)
69647A48 172.16.1.1.26322 172.16.1.2.179 ESTAB
6868C0A8 0.0.0.0.179 172.16.1.2.* LISTEN
r1#
*Oct 27 07:28:48: %BGP-3-NOTIFICATION: sent to neighbor 172.16.1.2 4/0 (hold time expired) 0 bytes
r1#
*Oct 27 07:28:48: %BGP-5-NBR_RESET: Neighbor 172.16.1.2 reset (BGP Notification sent)
*Oct 27 07:28:48: %BGP-5-ADJCHANGE: neighbor 172.16.1.2 Down BGP Notification sent
*Oct 27 07:28:48: %BGP_SESSION-5-ADJCHANGE: neighbor 172.16.1.2 IPv4 Unicast topology base removed from session BGP Notification sent
r1#sh tcp brie all
TCB Local Address Foreign Address (state)
67ECC48C 172.16.1.1.14286 172.16.1.2.179 SYNSENT
6868C0A8 0.0.0.0.179 172.16.1.2.* LISTEN
r1#sh tcp brie all
TCB Local Address Foreign Address (state)
69647A48 172.16.1.1.40204 172.16.1.2.179 CLOSED
696480CC 172.16.1.1.16103 172.16.1.2.179 SYNSENT
6868C0A8 0.0.0.0.179 172.16.1.2.* LISTEN
r1#sh ip bgp summ
BGP router identifier 1.1.1.1, local AS number 100
BGP table version is 3, main routing table version 3
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.1.2 4 200 0 0 1 0 0 00:04:07 Active
r1#
then no shut the neighbor...
*Oct 27 07:34:05: %BGP-5-ADJCHANGE: neighbor 172.16.1.2 Up
r1#sh tcp brie all
TCB Local Address Foreign Address (state)
67ECC48C 172.16.1.1.179 172.16.1.2.52928 ESTAB
6868C0A8 0.0.0.0.179 172.16.1.2.* LISTEN
r1#sh ip bgp
BGP table version is 4, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 172.16.1.2 0 0 200 i
link state v dv...
ospf, like is-is is a link state
protocol...both are based on dijkstra's algrithm, also known as
distributed database protocols, each router originates information
about itself, it's directly connected links, and states of those
links... thus link state... they pass this information and make copies
of it between routers, but never change it... this makes for identical
views of the overall network topology...
an
older definition of eigrp is that it is a hybrid routing protocol;
sharing the best qualities of distance vector and link state....
actually there are no link state qualities to eigrp and it has more
correctly come to be known as an "advanced distance vector" protocol
based on a distributed form of the bellman-ford algorithm... vectors of
distance are exchanged between nodes, and resultant distances between
nodes, but an overall picture of the topology is not assembled, as in
link state...
as
jeff doyle puts it, "distance vector is a road sign while link state is
a road map", in his book which compares ospf and isis...
Friday, October 26, 2012
prepending...
/pree'pend'/ (by analogy with "append") To prefix or add to the beginning.
according to odom in ccnp route ocg:
Monday, October 22, 2012
ipv6 addresses...
when i see an ipv6 address, i see groups of four digits separated by colons...
each of those four digits in hex will ultimately become 2 numbers separated by a
dot in decimal... but first i see them as 2 pair, ie. 2001: is 20 and 01... each
number in each of those pairs are place holders... the left most number
in each pair is the 16's place holder while the number to the right of
it is the units place holder... so 20 = 16x2 + 0 =32 and 01 = 16x0 +1 =1
or 32.1... of course, if a leading zero is
missing, there is no 16's place holder, just a units place holder.
the left number is the 16's place holder and will be multiplied by 16, and it's number to the right is expressed in units...
so :1111: is 11 and 11 or 16x1 + 1 =17 and 16x1 + 1 = 17 and finally 17.17
so...
:0db8: = 0d and b8 = 16x0+13 = 13 and 16x11+8=184 or 13.184
now here's a bar bet winner...
what is the hex equivalent of decimal 20?
20/16 is 1 remainder 4 or 1 4 or 14...
try it with a hex/decimal converter...
you know i'm right but you'll have to prove it for yourself... won't you?
the left number is the 16's place holder and will be multiplied by 16, and it's number to the right is expressed in units...
so :1111: is 11 and 11 or 16x1 + 1 =17 and 16x1 + 1 = 17 and finally 17.17
so...
:0db8: = 0d and b8 = 16x0+13 = 13 and 16x11+8=184 or 13.184
now here's a bar bet winner...
what is the hex equivalent of decimal 20?
20/16 is 1 remainder 4 or 1 4 or 14...
try it with a hex/decimal converter...
you know i'm right but you'll have to prove it for yourself... won't you?
quote of the day... bgp states, in order...
from chris bryant... well done...
http://archive.networknewz.com/networknewz-10-20060403BGPAdjacencyStates.html
Idle is the initial state of a BGP connection. The BGP speaker is waiting for a start event, generally either the establishment of a TCP connection or the re-establishment of a previous connection. Once the connection is established, BGP moves to the next state.
Connect is the next state. If the TCP connection completes, BGP will move to the OpenSent stage if the connection does not complete, BGP goes to Active.
Active indicates that the BGP speaker is continuing to create a peer relationship with the remote router. If this is successful, the BGP state goes to OpenSent. You'll occasionally see a BGP connection flap between Active and Connect. This indicates an issue with the physical cable itself, or with the configuration.
OpenSent indicates that the BGP speaker has received an Open message from the peer. BGP will determine whether the peer is in the same AS (iBGP) or a different AS (eBGP) in this state.
In OpenConfirm state, the BGP speaker is waiting for a keepalive message. If one is received, the state moves to Established, and the neighbor relationship is complete. It is in the Established state that update packets are actually exchanged.
http://archive.networknewz.com/networknewz-10-20060403BGPAdjacencyStates.html
Idle is the initial state of a BGP connection. The BGP speaker is waiting for a start event, generally either the establishment of a TCP connection or the re-establishment of a previous connection. Once the connection is established, BGP moves to the next state.
Connect is the next state. If the TCP connection completes, BGP will move to the OpenSent stage if the connection does not complete, BGP goes to Active.
Active indicates that the BGP speaker is continuing to create a peer relationship with the remote router. If this is successful, the BGP state goes to OpenSent. You'll occasionally see a BGP connection flap between Active and Connect. This indicates an issue with the physical cable itself, or with the configuration.
OpenSent indicates that the BGP speaker has received an Open message from the peer. BGP will determine whether the peer is in the same AS (iBGP) or a different AS (eBGP) in this state.
In OpenConfirm state, the BGP speaker is waiting for a keepalive message. If one is received, the state moves to Established, and the neighbor relationship is complete. It is in the Established state that update packets are actually exchanged.
Sunday, October 21, 2012
bgp synchronization...
from: http://www.enterprisenetworkingplanet.com/netsp/article.php/3617346/Networking-101--Understanding-iBGP.htm
When you enable synchronization on a router, this means that the IGP (iBGP in this case) and EGP must have the same information before those routes are used. The basic design
principal of a
transit AS is that you don’t advertise something until you can forward traffic to that
route
from: http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a00800949e8.shtml#nineteen
If your AS passes traffic from another AS to a third AS, BGP should not advertise a route before all routers in your AS learn about the route via IGP. BGP waits until IGP propagates the route within the AS and then advertises it to external peers. A BGP router with synchronization enabled does not install iBGP learned routes into its routing table if it is not able to validate those routes in its IGP
and this excellent example...
http://ciscodreamer.blogspot.com/2009/03/bgp-synchronization.html
i'll have to see it for myself...
When you enable synchronization on a router, this means that the IGP (iBGP in this case) and EGP must have the same information before those routes are used. The basic design
principal of a
transit AS is that you don’t advertise something until you can forward traffic to that
routefrom: http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a00800949e8.shtml#nineteen
If your AS passes traffic from another AS to a third AS, BGP should not advertise a route before all routers in your AS learn about the route via IGP. BGP waits until IGP propagates the route within the AS and then advertises it to external peers. A BGP router with synchronization enabled does not install iBGP learned routes into its routing table if it is not able to validate those routes in its IGP
and this excellent example...
http://ciscodreamer.blogspot.com/2009/03/bgp-synchronization.html
i'll have to see it for myself...
bgp update...
the update tells you the shit... you can just read it and expect to know it... you have to be it...
the update message (type 2)
origin, code 1, well known transitive
as_path, code 2, well known transitive
next_hop, code 3, well known transitive
and nlri follows...
zoom in...
the update message (type 2)
origin, code 1, well known transitive
as_path, code 2, well known transitive
next_hop, code 3, well known transitive
and nlri follows...
zoom in...
The mandatory category refers to an attribute that MUST be present in
both IBGP and EBGP exchanges if NLRI are contained in the UPDATE
message. Attributes classified as optional for the purpose of the
protocol extension mechanism may be purely discretionary,
discretionary, required, or disallowed in certain contexts.
attribute EBGP IBGP
ORIGIN mandatory mandatory
AS_PATH mandatory mandatory
NEXT_HOP mandatory mandatory
MULTI_EXIT_DISC discretionary discretionary
LOCAL_PREF see Section 5.1.5 required
ATOMIC_AGGREGATE see Section 5.1.6 and 9.1.4
AGGREGATOR discretionary discretionary
ORIGIN is a well-known mandatory attribute. The ORIGIN attribute is generated by the speaker that originates the associated routing information. Its value SHOULD NOT be changed by any other speaker.
AS_PATH is a well-known mandatory attribute. This attribute identifies the autonomous systems through which routing information carried in this UPDATE message has passed. The components of this list can be AS_SETs or AS_SEQUENCEs.
The NEXT_HOP is a well-known mandatory attribute that defines the IP address of the router that SHOULD be used as the next hop to the destinations listed in the UPDATE message.
what doyle says
Well-known attributes are either mandatory, meaning that they must be included in all BGP
Update messages, or they are discretionary , meaning that they may or may not be sent in a
specific Update message.
If an optional attribute is transitive , a BGP process should accept the path in which it is
included, even if it doesn’t support the attribute, and it should pass the path on to its peers.
If an optional attribute is nontransitive , a BGP process that does not recognize the attribute
can quietly ignore the Update in which it is included and not advertise the path to its other
peers.
ORIGIN is a well-known mandatory attribute that specifies the origin of the routing update.
When BGP has multiple routes, it uses the ORIGIN as one factor in determining the
preferred route.
AS_PATH is a well-known mandatory attribute that uses a sequence of AS numbers to describe the inter-AS path, or route, to the destination specified by the NLRI. When a BGP speaker originates a route—when it advertises NLRI about a destination within its own AS—it adds its AS number to the AS_PATH. As subsequent BGP speakers advertise the route to external peers, they prepend their own AS numbers to the AS_PATH
The NEXT_HOP Attribute
As the name implies, this well-known mandatory attribute describes the IP address of the
next-hop router on the path to the advertised destination. The IP address described by the
BGP NEXT_HOP attribute is not always the address of a neighboring router.
jeff has prettier fonts and stuff...
bgp notification...
to get a notification message, there needs to be an error... changing the neighbor remote-as will effect such an error...
look at the message types in rfc4271:
look at the message types in rfc4271:
Type:
This 1-octet unsigned integer indicates the type code of the
message. This document defines the following type codes:
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
open
After a TCP connection is established, the first message sent by each
side is an OPEN message. If the OPEN message is acceptable, a
KEEPALIVE message confirming the OPEN is sent back.UPDATE messages are used to transfer routing information between BGP peers.
An UPDATE message MAY simultaneously advertise a feasible route and withdraw multiple unfeasible routes from service.
A NOTIFICATION message is sent when an error condition is detected. The BGP connection is closed immediately after it is sent.
Keepalive
BGP does not use any TCP-based, keep-alive mechanism to determine if peers are reachable. Instead, KEEPALIVE messages are exchanged between peers often enough not to cause the Hold Timer to expire.
bgp-4, the classful internet killer...
rfc4271...
if rfc's scare you, there is this, however the first page is literally lifted from the rfc...
http://www.bgp4.as/
a fellow network guy i know scoffed at the idea of reading rfc's, as if it was some sort of highbrow pursuit, or a networking holier than thou kind of thing... to that i shake my head in bewilderment and cry bullshit... this is the path we have chosen; rfc's are the trail markers... get used to it... they don't have the pretty pictures, they don't hold your hand, the language can oftentimes seem shakespearian... the texts you read from the publishers are based on the rfc's, for God's sake... rfc's are the source... everything else is regurge...
read em and let the other guy weep...
and don't skip the acknowledgements... they are generally a who's who of network pioneers... radia perlman, russ white, john moy, vint cerf, et al... if these names mean nothing to you, you are in the wrong line of work...
BGP-4 provides a set of mechanisms for supporting Classless Inter- Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771.
if rfc's scare you, there is this, however the first page is literally lifted from the rfc...
http://www.bgp4.as/
a fellow network guy i know scoffed at the idea of reading rfc's, as if it was some sort of highbrow pursuit, or a networking holier than thou kind of thing... to that i shake my head in bewilderment and cry bullshit... this is the path we have chosen; rfc's are the trail markers... get used to it... they don't have the pretty pictures, they don't hold your hand, the language can oftentimes seem shakespearian... the texts you read from the publishers are based on the rfc's, for God's sake... rfc's are the source... everything else is regurge...
read em and let the other guy weep...
and don't skip the acknowledgements... they are generally a who's who of network pioneers... radia perlman, russ white, john moy, vint cerf, et al... if these names mean nothing to you, you are in the wrong line of work...
The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses.
a BGP speaker advertises to its peers only those routes that it uses itself
Routing information exchanged via BGP supports only the destination- based forwarding paradigm, which assumes that a router forwards a packet based solely on the destination address carried in the IP header of the packet. This, in turn, reflects the set of policy decisions that can (and cannot) be enforced using BGP.
The classic definition of an Autonomous System is a set of routers under a single technical administration, using an interior gateway protocol (IGP) and common metrics to determine how to route packets within the AS, and using an inter-AS routing protocol to determine how to route packets to other ASes.
BGP uses TCP [RFC793] as its transport protocol. This eliminates the need to implement explicit update fragmentation, retransmission, acknowledgement, and sequencing. BGP listens on TCP port 179. The error notification mechanism used in BGP assumes that TCP supports a "graceful" close (i.e., that all outstanding data will be delivered before the connection is closed). A TCP connection is formed between two systems. They exchange messages to open and confirm the connection parameters.
KEEPALIVE messages may be sent periodically to ensure that the connection is live. NOTIFICATION messages are sent in response to errors or special conditions. If a connection encounters an error condition, a NOTIFICATION message is sent and the connection is closed.
quote of the day, doyle, bgp path attributes...
this gets it right, and is clear... thanks jeff...
Well-known attributes are either mandatory, meaning that they must be included in all BGP Update messages, or they are discretionary , meaning that they may or may not be sent in a specific Update message.
If an optional attribute is transitive , a BGP process should accept the path in which it is included, even if it doesn’t support the attribute, and it should pass the path on to its peers.
If an optional attribute is nontransitive , a BGP process that does not recognize the attribute can quietly ignore the Update in which it is included and not advertise the path to its other
peers.
Well-known attributes are either mandatory, meaning that they must be included in all BGP Update messages, or they are discretionary , meaning that they may or may not be sent in a specific Update message.
If an optional attribute is transitive , a BGP process should accept the path in which it is included, even if it doesn’t support the attribute, and it should pass the path on to its peers.
If an optional attribute is nontransitive , a BGP process that does not recognize the attribute can quietly ignore the Update in which it is included and not advertise the path to its other
peers.
Saturday, October 20, 2012
quote of the day, doyle...
The outgoing traffic from the subscriber’s AS is the result of the default route, and the incoming traffic to the subscriber’s AS is the result of the route advertised by the ISP’s router.
routing tcpip, vol II, pg 79
oftentimes the most evident idea is the least grasped...
routing tcpip, vol II, pg 79
oftentimes the most evident idea is the least grasped...
post 600...
that's 50 posts a month average... since november 2011...
to celebrate, we take a look at synchronization...
eigrp and ospf have somewhat similar ideas about synchronization, bgp on the other hand (of course) gives it an entirely different meaning...
eigrp:
in eigrp, synchronization is synonymous with network convergence...
from: http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfeigrp.html
Diffusing Update Algorithm (DUAL) algorithm guarantees loop-free operation at every instant throughout a route computation and allows all devices involved in a topology change to synchronize at the same time. Routers that are not affected by topology changes are not involved in recomputations. The convergence time with DUAL rivals that of any other existing routing protocol.
ospf's synchronization concern is it's database, naturally with the intent to form adjacencies...
from rfc 2328:
with bgp, however:
http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a00800949e8.shtml#nineteen
If your AS passes traffic from another AS to a third AS, BGP should not advertise a route before all routers in your AS learn about the route via IGP. BGP waits until IGP propagates the route within the AS and then advertises it to external peers. A BGP router with synchronization enabled does not install iBGP learned routes into its routing table if it is not able to validate those routes in its IGP. Issue the no synchronization command under router bgp in order to disable synchronization. This prevents BGP from validating iBGP routes in IGP. Refer to BGP Case Studies: Synchronization for a more detailed explanation.
to celebrate, we take a look at synchronization...
eigrp and ospf have somewhat similar ideas about synchronization, bgp on the other hand (of course) gives it an entirely different meaning...
eigrp:
in eigrp, synchronization is synonymous with network convergence...
from: http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfeigrp.html
Diffusing Update Algorithm (DUAL) algorithm guarantees loop-free operation at every instant throughout a route computation and allows all devices involved in a topology change to synchronize at the same time. Routers that are not affected by topology changes are not involved in recomputations. The convergence time with DUAL rivals that of any other existing routing protocol.
ospf's synchronization concern is it's database, naturally with the intent to form adjacencies...
from rfc 2328:
7.2. The Synchronization of Databases
In a link-state routing algorithm, it is very important for all
routers' link-state databases to stay synchronized. OSPF
simplifies this by requiring only adjacent routers to remain
synchronized. The synchronization process begins as soon as the
routers attempt to bring up the adjacency.
with bgp, however:
http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a00800949e8.shtml#nineteen
If your AS passes traffic from another AS to a third AS, BGP should not advertise a route before all routers in your AS learn about the route via IGP. BGP waits until IGP propagates the route within the AS and then advertises it to external peers. A BGP router with synchronization enabled does not install iBGP learned routes into its routing table if it is not able to validate those routes in its IGP. Issue the no synchronization command under router bgp in order to disable synchronization. This prevents BGP from validating iBGP routes in IGP. Refer to BGP Case Studies: Synchronization for a more detailed explanation.
ipv6 header...
turn on ipv6 between two routers, use ospf on the interfaces and look at a header cap just like Iljitsch said... how do you pronounce that? ill-jitch?
as jitchy says, the header length is no longer required because the ipv6 header is always 40 bytes long... there is comfort in that...
according to rfc2460:
the header checksum is gone and source and destination are painfully obvious, excepting being 4X as long... (32 v 128)
read this http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-3/ipv6_internals.html
or the last post for jitchy's v4/v6 comparison...
by virtue of less fields, no checksum, always 40 bytes, it is streamlined...
IPv6 no longer has a header checksum to protect the IP header, meaning that when a packet header is corrupted by transmission errors, the packet is very likely to be delivered incorrectly. However, higher-layer protocols should be able to detect these problems, so they are not fatal. Also, lower layers almost always employ a Cyclic Redundancy Check (CRC) to detect errors.
as jitchy says, the header length is no longer required because the ipv6 header is always 40 bytes long... there is comfort in that...
according to rfc2460:
Version 4-bit Internet Protocol version number = 6.
Traffic Class 8-bit traffic class field. See section 7.
Flow Label 20-bit flow label. See section 6.
Payload Length 16-bit unsigned integer. Length of the IPv6
payload, i.e., the rest of the packet following
this IPv6 header, in octets. (Note that any
extension headers [section 4] present are
considered part of the payload, i.e., included
in the length count.)
Next Header 8-bit selector. Identifies the type of header
immediately following the IPv6 header. Uses the
same values as the IPv4 Protocol field [RFC-1700
et seq.].
Hop Limit 8-bit unsigned integer. Decremented by 1 by
each node that forwards the packet. The packet
is discarded if Hop Limit is decremented to
zero.
the header checksum is gone and source and destination are painfully obvious, excepting being 4X as long... (32 v 128)
read this http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-3/ipv6_internals.html
or the last post for jitchy's v4/v6 comparison...
by virtue of less fields, no checksum, always 40 bytes, it is streamlined...
IPv6 no longer has a header checksum to protect the IP header, meaning that when a packet header is corrupted by transmission errors, the packet is very likely to be delivered incorrectly. However, higher-layer protocols should be able to detect these problems, so they are not fatal. Also, lower layers almost always employ a Cyclic Redundancy Check (CRC) to detect errors.
Friday, October 19, 2012
by Iljitsch van Beijnum...
say his name 1 time fast...
just when you thought it was safe to go back in the water... blame it on however you pronounce his name... it simply never ends...
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-3/ipv6_internals.html
The fields in the IPv4 header that are not present in the IPv6 header have gray text; the field that is present in IPv6 but not in IPv4 is shown in italic. The changes from IPv4 to IPv6 follow:
The TCP, UDP, and ICMPv6 checksums are computed over a “pseudoheader” and the TCP, UDP, or ICMPv6 header, and user data, respectively. The pseudoheader consists of the source and destination addresses, the upper-layer packet length, and the protocol number. Including this information in the checksum calculation ensures that TCP, UDP, or ICMPv6 do not process packets that were delivered incorrectly, for instance, because of a bit error in the IP header.
IPv6 no longer has a header checksum to protect the IP header, meaning that when a packet header is corrupted by transmission errors, the packet is very likely to be delivered incorrectly. However, higher-layer protocols should be able to detect these problems, so they are not fatal. Also, lower layers almost always employ a Cyclic Redundancy Check (CRC) to detect errors.
just when you thought it was safe to go back in the water... blame it on however you pronounce his name... it simply never ends...
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_9-3/ipv6_internals.html
Differences Between IPv4 and IPv6
All knowledge about IPv6 begins with studying the IPv6 header format and the ways in which it is different from the IPv4 header format. Even though at the time the IPv6 specifications were written 64-bit CPUs were rare, the IPv6 designers elected to optimize the IPv6 header for 64-bit processing. For this reason, I have drawn the IPv6 header 64 bits wide in Figure 1, a little different from the way it is usually depicted. Because 64-bit CPUs can read one 64-bit-wide memory word at a time, it is helpful that fields that are 64 bits (or a multiple of 64 bits) wide start at an even 64-bit boundary. Because every 64-bit boundary is also a 32-bit boundary, 32-bit CPUs aren’t affected negatively by 64-bit optimization. The IPv4 header is presented in the usual form that highlights its 32-bit background.The fields in the IPv4 header that are not present in the IPv6 header have gray text; the field that is present in IPv6 but not in IPv4 is shown in italic. The changes from IPv4 to IPv6 follow:
- Version now always contains 6 rather than 4.
- The Internet Header Length (IHL) field that indicates the length of the IPv4 header is no longer needed because the IPv6 header is always 40 bytes long.
- Type of Service is now Traffic Class. The original semantics of the IPv4 Type of Service field have been superseded by the diffserv semantics per RFC 2474 [3]. However, in IPv4, both interpretations of the field are in use (although most routers either cannot or are not configured to look at the field anyway). The IPv6 RFCs do not mandate a specific way to use the Traffic Class field, but generally the RFC 2474 diffserv interpretation is assumed.
- The Flow Label is new in IPv6. The idea is that packets belonging to the same stream, session, or flow share a common flow label value, making the session easily recognizable without having to look “deep” into the packet. Recognizing a stream or session is often useful in Quality of Service mechanisms. Although few implementations actually look at the flow label, most systems do set different flow labels for packets belonging to different TCP sessions. A zero value in this field means that setting a flow label per session is either not supported or not desired.
- The Total Length is the length of the IPv4 packet including the header, but in IPv6, the Payload Length does not include the 40-byte IPv6 header, thereby saving the host or router receiving a packet from having to check whether the packet is large enough to hold the IP header in the first place—making for a small efficiency gain. Despite the name, the Payload Length field includes the length of any additional headers, not just the length of the user data.
- The Identification, Flags, and Fragment Offset fields are used when IPv4 packets must be fragmented. Fragmentation in IPv6 works very differently (explained later), so these fields are relegated to a header of their own.
- Time to Live (TTL) is now called Hop Limit. This field is initialized with a suitable value at the origin of a packet and decremented by each router along the way. When the field reaches zero, the packet is destroyed. This way, packets cannot circle the network forever when there are loops. Per RFC 791 [4], the IPv4 TTL field should be decremented by the number of seconds that a packet is buffered in a router, but keeping track of how long packets are buffered is too difficult to implement, regardless of buffering time. The new name is a better description of what actually happens.
- The Protocol field in IPv4 is replaced by Next Header in IPv6. In both cases, the field indicates the type of header that follows the IPv4 or IPv6 header. In most cases, the value of this field would be 6 for TCP or 17 for the User Datagram Protocol (UDP). Because the IPv6 header has a fixed length, any options such as source routing or fragmentation must be implemented as additional headers that sit between the IPv6 header and the higher-layer protocol such as TCP, forming a “protocol chain.”
- The IPv4 Header Checksum was removed in IPv6.
- The Source Address and Destination Address serve the same function in IPv6 as in IPv4, except that they are now four times as long at 128 bits.
Checksums
In IPv4, the IP header is protected by a header checksum, and higher-layer protocols generally also have a checksum. The checksum algorithm for the IPv4 header, Internet Control Message Protocol (ICMP), ICMPv6, TCP, and UDP is the same one’s complement addition, except that in IPv4, UDP packets may forego checksumming and simply set the checksum field to zero. In IPv6, this practice is no longer allowed: UDP packets must have a valid checksum.The TCP, UDP, and ICMPv6 checksums are computed over a “pseudoheader” and the TCP, UDP, or ICMPv6 header, and user data, respectively. The pseudoheader consists of the source and destination addresses, the upper-layer packet length, and the protocol number. Including this information in the checksum calculation ensures that TCP, UDP, or ICMPv6 do not process packets that were delivered incorrectly, for instance, because of a bit error in the IP header.
IPv6 no longer has a header checksum to protect the IP header, meaning that when a packet header is corrupted by transmission errors, the packet is very likely to be delivered incorrectly. However, higher-layer protocols should be able to detect these problems, so they are not fatal. Also, lower layers almost always employ a Cyclic Redundancy Check (CRC) to detect errors.
Extension Headers
To allow special processing along the way, IPv4 allows extension of the IP header with one or more options. These options are rarely used today, both because they do not really solve common problems and because packets with options cannot be processed in the “fast path,” and many routers and firewalls block some or all options. Not unlike the checkout counters at a grocery store, many routers have several “paths” that packets may follow: a fast one, implemented in hardware or highly optimized software, that supports only the most common operations (no checks), and one or more slower paths that use more advanced but slower software code that supports less common operations such as looking at IP options. However, many modern routers have only a fast path, so using additional features does not lead to a performance penalty.external attribute lsa and opaque...
so, here we have the avoided/able lsa types, brought to you by
http://www.inetdaemon.com/tutorials/internet/ip/routing/ospf/index.shtml
Types (by type code)
to the moon, alice...
number 8 is a give away as well... attributes? hmmm...
from wiki:
that concludes your ospf trivia for tonight...
http://www.inetdaemon.com/tutorials/internet/ip/routing/ospf/index.shtml
Types (by type code)
- 1 - Router LSA
- 2 - Network LSA
- 3 - Network summary LSA
- 4 - ASBR Summary LSA
- 5 - AS External LSA
- 6 - Group Membership LSA
- 7 - NSSA External LSA
- 8 - External Attributes LSA
- 9 - Opaque LSA (link-local scope)
- 10 - Opaque LSA (area-local scope)
- 11 - Opaque LSA (AS scope)
MOSPF routers use the IGMP protocol to monitor multicast group membership on local LANs through the sending of IGMP Host Membership Queries and the reception of IGMP Host Membership Reports.
to the moon, alice...
number 8 is a give away as well... attributes? hmmm...
from wiki:
- Type 8 - A link-local only LSA for OSPFv3. A Type 8 LSA is used to give information about link-local addresses and a list of IPv6 addresses on the link. In OSPFv2, however, the Type 8 was originally intended to be used as a so-called External-Attributes-LSA for transit autonomous systems where OSPFv2 could replace the internal Border Gateway Protocol (iBGP). In these networks, the BGP destinations would be carried in LSA Type 5 while their BGP attributes would be inserted into LSA Type 8. Most OSPFv2 implementations never supported this feature.
- Type 9 - a link-local "opaque" LSA (defined by RFC2370) in OSPFv2 and the Intra-Area-Prefix LSA in OSPFv3. It is the OSPFv3 LSA that contains prefixes for stub and transit networks in the link-state ID.
- Type 10 - an area-local "opaque" LSA as defined by RFC2370. Opaque LSAs contain information which should be flooded by other routers even if the router is not able to understand the extended information itself. Typically type 10 LSAs are used for traffic engineering extensions to OSPF, flooding extra information about links beyond just their metric, such as link bandwidth and color.
- Type 11 - an AS "opaque" LSA defined by RFC 5250, which is flooded everywhere except stub areas. This is the opaque equivalent of the type 5 external LSA.[3]
that concludes your ospf trivia for tonight...
ipv6...
because you never get sick of it...
c'mon, it's about the future... it's only going to become more important...
check out this phenomenal site...
http://www.ipv6.com/articles/general/IPv6-Addressing.htm
Types of IPv6 Addresses
IPv6 addresses are broadly classified into three categories:
1) Unicast addresses A Unicast address acts as an identifier for a single interface. An IPv6 packet sent to a Unicast address is delivered to the interface identified by that address.
2) Multicast addresses A Multicast address acts as an identifier for a group/set of interfaces that may belong to the different nodes. An IPv6 packet delivered to a Multicast address is delivered to the multiple interfaces.
3) Anycast addresses Anycast addresses act as identifiers for a set of interfaces that may belong to the different nodes. An IPv6 packet destined for an Anycast address is delivered to one of the interfaces identified by the address.
IPv6 Address Notation
IPv6 addresses are denoted by eight groups of hexadecimal quartets separated by colons in between them.
Following is an example of a valid IPv6 address: 2001:cdba:0000:0000:0000:0000:3257:9652
Any four-digit group of zeroes within an IPv6 address may be reduced to a single zero or altogether omitted. Therefore, the following IPv6 addresses are similar and equally valid:
2001:cdba:0000:0000:0000:0000:3257:9652
2001:cdba:0:0:0:0:3257:9652
2001:cdba::3257:9652
The URL for the above address will be of the form:
http://[2001:cdba:0000:0000:0000:0000:3257:9652]/
Network Notation in IPv6
The IPv6 networks are denoted by Classless Inter Domain Routing (CIDR) notation. A network or subnet using the IPv6 protocol is denoted as a contiguous group of IPv6 addresses whose size must be a power of two. The initial bits of an IPv6 address (these are identical for all hosts in a network) form the network s prefix. The size of bits in a network prefix are separated with a / . For example, 2001:cdba:9abc:5678::/64 denotes the network address 2001:cdba:9abc:5678. This network comprises of addresses rearranging from 2001:cdba:9abc:5678:: up to 2001:cdba:9abc:5678:ffff:ffff:ffff:ffff. In a similar fashion, a single host may be denoted as a network with a 128-bit prefix. In this way, IPv6 allows a network to comprise of a single host and above.
Special Addresses in IPv6
Reference: Please see RFC 1884 - IP Version 6 Addressing Architecture for more information.
c'mon, it's about the future... it's only going to become more important...
check out this phenomenal site...
http://www.ipv6.com/articles/general/IPv6-Addressing.htm
Types of IPv6 Addresses
IPv6 addresses are broadly classified into three categories:
1) Unicast addresses A Unicast address acts as an identifier for a single interface. An IPv6 packet sent to a Unicast address is delivered to the interface identified by that address.
2) Multicast addresses A Multicast address acts as an identifier for a group/set of interfaces that may belong to the different nodes. An IPv6 packet delivered to a Multicast address is delivered to the multiple interfaces.
3) Anycast addresses Anycast addresses act as identifiers for a set of interfaces that may belong to the different nodes. An IPv6 packet destined for an Anycast address is delivered to one of the interfaces identified by the address.
IPv6 Address Notation
IPv6 addresses are denoted by eight groups of hexadecimal quartets separated by colons in between them.
Following is an example of a valid IPv6 address: 2001:cdba:0000:0000:0000:0000:3257:9652
Any four-digit group of zeroes within an IPv6 address may be reduced to a single zero or altogether omitted. Therefore, the following IPv6 addresses are similar and equally valid:
2001:cdba:0000:0000:0000:0000:3257:9652
2001:cdba:0:0:0:0:3257:9652
2001:cdba::3257:9652
The URL for the above address will be of the form:
http://[2001:cdba:0000:0000:0000:0000:3257:9652]/
Network Notation in IPv6
The IPv6 networks are denoted by Classless Inter Domain Routing (CIDR) notation. A network or subnet using the IPv6 protocol is denoted as a contiguous group of IPv6 addresses whose size must be a power of two. The initial bits of an IPv6 address (these are identical for all hosts in a network) form the network s prefix. The size of bits in a network prefix are separated with a / . For example, 2001:cdba:9abc:5678::/64 denotes the network address 2001:cdba:9abc:5678. This network comprises of addresses rearranging from 2001:cdba:9abc:5678:: up to 2001:cdba:9abc:5678:ffff:ffff:ffff:ffff. In a similar fashion, a single host may be denoted as a network with a 128-bit prefix. In this way, IPv6 allows a network to comprise of a single host and above.
Special Addresses in IPv6
 |
::/96 The zero prefix denotes addresses that are compatible with the previously used IPv4 protocol. |
|
|
::/128 An IPv6 address with all zeroes
in it is referred to as an unspecified address and is used for
addressing purposes within a software. |
|
|
::1/128 This is called the loop back
address and is used to refer to the local host. An application sending a
packet to this address will get the packet back after it is looped back
by the IPv6 stack. The local host address in the IPv4 was 127.0.0.1 . |
|
|
2001:db8::/32 This is a documentation
prefix allowed in the IPv6. All the examples of IPv6 addresses should
ideally use this prefix to indicate that it is an example. |
|
|
fec0::/10 This is a site-local prefix
offered by IPv6. This address prefix signifies that the address is valid
only within the local organization. Subsequently, the usage of this
prefix has been discouraged by the RFC. |
|
|
fc00::/7 This is called the Unique
Local Address (ULA). These addresses are routed only within a set of
cooperating sites. These were introduced in the IPv6 to replace the
site-local addresses. These addresses also provide a 40-bit pseudorandom
number that reduces the risk of address conflicts. |
|
|
ff00::/8 This prefix is offered by
IPv6 to denote the multicast addresses. Any address carrying this prefix
is automatically understood to be a multicast address. |
|
|
fe80::/10 This is a link-local prefix
offered by IPv6. This address prefix signifies that the address is valid
only in the local physical link. |
Reference: Please see RFC 1884 - IP Version 6 Addressing Architecture for more information.
ipv6 m'cast...
mcast address mcast group
FF01::1 IPv6 nodes/node-local scope
FF01::2 IPv6 routers/node-local scope
FF02::1 IPv6 nodes/link-local scope
FF02::2 IPv6 routers/link-local scope
FF02::5 OSPFv3 router/link-local scope
FF02::6 OSPFv3
designated routers/link-local scope
FF02::9 RIPng routers/link-local scope
FF02::A EIGRP routers/link-local scope
FF02::D PIM routers/link-local scope
FF02::1:2 DHCPv6 agents/link-local scope
FF05::2 IPv6 routers/site-local scope
FF02::1:FF00:0/104 IPv6
solicited-node multicast address/link-local scope
have you memorized them yet...
Subscribe to:
Posts (Atom)