OSPF Neighbor States

OSPF Neighbor States

Down

Attempt  / send hello

Init     / received hello (check hello/dead timers, netmasks, AREA ID, Auth)

Two Way  / hellos received by both neighbors – reset dead timer and wait for another hello. repeat (The only exception to this is the 2-way state, which is normal in a broadcast network. Routers achieve the full state with their DR and BDR only. Neighbors always see each other as 2-way)

Exstart  / Master(higher priority) and slave exchange DBD packets summary of LSDB

Exchange / DBDs ack and review LSR

Loading  / LSU exchange between Master/Slave

Full     / LSDB is the same

Now time to run the Dijkstra SPF algorithm and create routes for routing table

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f0e.shtml

Advertisements

Two ways to set iBGP “next-hop-self” for full reachability

Q. Do internal BGP (iBGP) sessions modify the next hop?

A. iBGP sessions preserve the next hop attribute learned from eBGP peers. This is why it is important to have an internal route to the next hop. The BGP route is otherwise unreachable. In order to make sure you can reach the eBGP next hop, include the network that the next hop belongs to in the IGP or issue the next-hop-self neighbor command to force the router to advertise itself, rather than the external peer, as the next hop. Refer to the BGP Next Hop Attribute section of BGP Case Studies for a more detailed explanation.

http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a00800949e8.shtml

BGP_next-hop-self

1st standard way using ‘next-hop-self’ on iBGP (eBGP conneted router upstream)

R3(config-if)#do sh run | s bgp
router bgp 34
no synchronization
bgp log-neighbor-changes
network 4.4.4.4 mask 255.255.255.255
network 34.34.34.0 mask 255.255.255.0
neighbor 13.13.13.1 remote-as 12
neighbor 13.13.13.1 send-community both
neighbor 13.13.13.1 route-map 34->12 out
neighbor 23.23.23.2 remote-as 21
neighbor 34.34.34.4 remote-as 34
neighbor 34.34.34.4 next-hop-self

R4(config-router)#do sh ip bgp
BGP table version is 44, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network          Next Hop            Metric LocPrf Weight Path
r>i4.4.4.4/32       34.34.34.3               2    100      0 i
*>i8.8.8.8/32       34.34.34.3               0    100      0 12 i
r>i34.34.34.0/24    34.34.34.3               0    100      0 i

R3(config-router)#no  neighbor 34.34.34.4 next-hop-self

R4#sh ip bgp
BGP table version is 43, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network          Next Hop            Metric LocPrf Weight Path
r>i4.4.4.4/32       34.34.34.3               2    100      0 i
* i8.8.8.8/32       13.13.13.1               0    100      0 12 i
r>i34.34.34.0/24    34.34.34.3               0    100      0 i

2nd way use route-map and set ‘ip next-hop peer-address’ command on downstream iBGP peer

R4(config)#route-map SET_NEXTHOP_PEER_ADDRESS
R4(config-route-map)#set ip next-hop peer-address
R4(config-route-map)#router bgp 34
R4(config-router)#neighbor 34.34.34.3 route-map SET_NEXTHOP_PEER_ADDRESS in
R4(config-router)#do clear ip bgp * soft in
R4(config-router)#
*Jul 26 20:38:52.371: RT: add 8.8.8.8/32 via 34.34.34.3, bgp metric [200/0]
*Jul 26 20:38:52.375: RT: NET-RED 8.8.8.8/32
R4(config-router)#do sh ip bgp
BGP table version is 44, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal,
r RIB-failure, S Stale
Origin codes: i – IGP, e – EGP, ? – incomplete

Network          Next Hop            Metric LocPrf Weight Path
r>i4.4.4.4/32       34.34.34.3               2    100      0 i
*>i8.8.8.8/32       34.34.34.3               0    100      0 12 i
r>i34.34.34.0/24    34.34.34.3               0    100      0 i

 

configurations files:

https://www.dropbox.com/s/vcdumrhr151yp6l/BGP_set_next-hop-self.zip

Central Services VPN layer 3 MPLS

CentralServicesVPNhttps://www.dropbox.com/s/8h9up4l3l4lmsnr/configs.zip

Traceroute from Server 8.8.8.8 to Client1 192.168.100.1
Server#traceroute 192.168.100.1 source 8.8.8.8
1 10.1.1.2 144 msec 32 msec 104 msec
2 129.53.22.2 [MPLS: Labels 18/20 Exp 0] 288 msec 548 msec 480 msec
3 129.53.12.1 [MPLS: Labels 18/20 Exp 0] 448 msec 520 msec 336 msec
4 192.168.1.2 [MPLS: Label 20 Exp 0] 164 msec 104 msec *
5 192.168.1.1 208 msec *  176 msec

PE2#sh mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     16            129.53.11.0/24    0             Fa0/0      129.53.22.2
17     Pop Label     129.53.12.0/24    0             Fa0/0      129.53.22.2
18     18            1.1.1.1/32        0             Fa0/0      129.53.22.2
19     No Label      8.8.8.8/32[V]     1692          Se1/0      point2point
20     No Label      10.1.1.0/24[V]    0             aggregate/Server

PE2#sh bgp vpnv4 unicast vrf Server 192.168.100.1/32
BGP routing table entry for 100:4:192.168.100.1/32, version 9
Paths: (1 available, best #1, table Server)
Not advertised to any peer
Local, imported path from 100:1:192.168.100.1/32
1.1.1.1 (metric 4) from 1.1.1.1 (1.1.1.1)
Origin incomplete, metric 2297856, localpref 100, valid, internal, best
Extended Community: RT:100:1 RT:100:100
Cost:pre-bestpath:128:2297856 (default-2145185791) 0x8800:32768:0
0x8801:1000:640000 0x8802:65281:1657856 0x8803:65281:1500
mpls labels in/out nolabel/20

P2#sh mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     129.53.11.0/24    0             Fa0/1      129.53.12.1
17     Pop Label     2.2.2.2/32        4001          Fa0/0      129.53.22.1
18     18            1.1.1.1/32        1607          Fa0/1      129.53.12.1

P1#sh mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     129.53.22.0/24    0             Fa0/1      129.53.12.2
17     17            2.2.2.2/32        4127          Fa0/1      129.53.12.2
18     Pop Label     1.1.1.1/32        2705          Fa0/0      129.53.11.1

PE1#sh mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     17            2.2.2.2/32        0             Fa0/0      129.53.11.2
17     16            129.53.22.0/24    0             Fa0/0      129.53.11.2
18     Pop Label     129.53.12.0/24    0             Fa0/0      129.53.11.2
19     No Label      192.168.1.0/24[V] 0             aggregate/Client1
20     No Label      192.168.100.1/32[V]   \
1152          Se1/0      point2point
21     No Label      172.16.1.0/24[V]  0             aggregate/Client2
22     No Label      172.16.200.2/32[V]   \
0             Se1/2      point2point

Traceroute from Client1 192.168.100.1 to Server 8.8.8.8

Client1#traceroute 8.8.8.8 source 192.168.100.1
1 192.168.1.2 16 msec 32 msec 4 msec
2 129.53.11.2 [MPLS: Labels 17/19 Exp 0] 108 msec 120 msec 96 msec
3 129.53.12.2 [MPLS: Labels 17/19 Exp 0] 108 msec 88 msec *
4 10.1.1.2 [MPLS: Label 19 Exp 0] 120 msec 72 msec 76 msec
5 10.1.1.1 80 msec *  140 msec

PE1#sh mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     17            2.2.2.2/32        0             Fa0/0      129.53.11.2
17     16            129.53.22.0/24    0             Fa0/0      129.53.11.2
18     Pop Label     129.53.12.0/24    0             Fa0/0      129.53.11.2
19     No Label      192.168.1.0/24[V] 0             aggregate/Client1
20     No Label      192.168.100.1/32[V]   \
1152          Se1/0      point2point
21     No Label      172.16.1.0/24[V]  0             aggregate/Client2
22     No Label      172.16.200.2/32[V]   \
0             Se1/2      point2point

PE1#sh bgp vpnv4 unicast vrf Client1 8.8.8.8/32
BGP routing table entry for 100:1:8.8.8.8/32, version 12
Paths: (1 available, best #1, table Client1)
Not advertised to any peer
Local, imported path from 100:4:8.8.8.8/32
2.2.2.2 (metric 4) from 2.2.2.2 (2.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:100:4 RT:100:101
mpls labels in/out nolabel/19

P1#sh mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     129.53.22.0/24    0             Fa0/1      129.53.12.2
17     17            2.2.2.2/32        4127          Fa0/1      129.53.12.2
18     Pop Label     1.1.1.1/32        2705          Fa0/0      129.53.11.1

P2#sh mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     Pop Label     129.53.11.0/24    0             Fa0/1      129.53.12.1
17     Pop Label     2.2.2.2/32        4001          Fa0/0      129.53.22.1
18     18            1.1.1.1/32        1607          Fa0/1      129.53.12.1

PE2#sh mpls forwarding-table
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
Label  Label or VC   or Tunnel Id      Switched      interface
16     16            129.53.11.0/24    0             Fa0/0      129.53.22.2
17     Pop Label     129.53.12.0/24    0             Fa0/0      129.53.22.2
18     18            1.1.1.1/32        0             Fa0/0      129.53.22.2
19     No Label      8.8.8.8/32[V]     1692          Se1/0      point2point
20     No Label      10.1.1.0/24[V]    0             aggregate/Server

no mpls ip propagate-ttl

P1(config)#no mpls ip propagate-ttl
P2(config)#no mpls ip propagate-ttl

Server#traceroute 192.168.100.1 source 8.8.8.8
Type escape sequence to abort.
Tracing the route to 192.168.100.1
1 10.1.1.2 32 msec 24 msec 28 msec
2 129.53.22.2 [MPLS: Labels 18/20 Exp 0] 100 msec 128 msec 92 msec
3 129.53.12.1 [MPLS: Labels 18/20 Exp 0] 116 msec 56 msec 132 msec
4 192.168.1.1 116 msec *  156 msec

Client1#traceroute 8.8.8.8 source 192.168.100.1
Type escape sequence to abort.
Tracing the route to 8.8.8.8
1 192.168.1.2 24 msec 48 msec 28 msec
2 129.53.11.2 [MPLS: Labels 17/19 Exp 0] 56 msec 120 msec 116 msec
3 129.53.12.2 [MPLS: Labels 17/19 Exp 0] 124 msec 104 msec 84 msec
4 10.1.1.1 92 msec *  120 msec

CentralServicesVPN

https://www.dropbox.com/s/s9yup9u4sof6jmu/CentralServicesVPN.pcap

VPLS Overview

“VPLS is a multipoint architecture that connects two or more customer devices using Ethernet bridging techniques over an MPLS network. In VPLS, the P-network emulates an IEEE 802.1D Ethernet bridge, with each EMS being analogous to a VLAN. VPLS is an architecture that is still being defined. There are two RFCs that are distinct and incompatible with one another: • RFC 4761: Virtual Private LAN Service (VPLS). Using BGP for Auto-Discovery and Signaling is a standard proposed by Juniper • RFC 4762: Virtual Private LAN Service (VPLS). Using Label Distribution Protocol (LDP) Signaling is a standard proposed by Cisco One of the major differences in the standard is in the VPLS PE discovery process, or how VPLS PE devices find each other, communicate capabilities, and perform tasks such as preprovisioning EVCs.”

“VPLS Architecture Model In the VPLS architecture model, UPE devices act as IEEE 802.1D standard bridges or switches. They are interconnected in a full mesh of PWs. In Figure 4-11, the PWs cross a routed MPLS and IP provider backbone. From the point of view of the UPEs, these PWs are just Ethernet connections to another switch.”

Cisco Systems, Inc. Virtual Private LAN Services (VPLS) Introduction at http://www.cisco.com/en/US/products/ps6648/products_ios_protocol_option_home.html

– Tiso, John (2011-10-31). Designing Cisco Network Service Architectures (ARCH) Foundation Learning Guide: (CCDP ARCH 642-874) (3rd Edition) (Foundation Learning Guides) (Kindle Locations 4279-4284). Pearson Education. Kindle Edition.

AToM Any Transport over MPLS RFCs

“The AToM framework and transport options for the various Layer 2 protocols are defined in RFC 4447, RFC 4385, RFC 4448, RFC 4717, RFC 4618, and RFC 4619. In addition to these methods to transport Layer 2 protocols, RFC 4553 and RFC 4842 define methods to transport TDM-based services, such as T1/E1, T3/E3, and SONET/SDH, over a core MPLS network.”   -Tiso, John (2011-10-31).  Designing Cisco Network Service Architectures (ARCH) Foundation Learning Guide: (CCDP ARCH 642-874) (3rd Edition) (Foundation Learning Guides) (Kindle Locations 4189-4191). Pearson Education. Kindle Edition.

Cisco Systems, Inc. MPLS Layer 2 VPNs—AToM at http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/ngmaneover.html#wp1058927

BSR (Boot Strap Router) step by step

BSR Boot Strap Router

1. Candidate BSR sends multicast message 224.0.0.13 to ALL Pim routers (PIM2 type4 message) to announce it is the candidate BSR, this is forwarded hop by hop as long as it passes RPF check
2. After best BSR is elected from step 1 C-BSR, the Candidate RPs announce themselves via Unicast RP-Announce message (PIMv2 type8 message) to the IP of the BSR
3. BSR will then flood C-RP along with hash value for PIM routers to choose the RP for each group (Now ALL PIM routers know the BSR, C-RPs and their groups. According to the hash-value advertised by the BSR)

links to detailed information and packet captures:
http://packetlife.net/captures/category/multicast/
http://cciethebeginning.wordpress.com/tag/boot-strap-router/

Compatibility with 802.1D from Understanding Rapid Spanning Tree Protocol (802.1w)

Compatibility with 802.1D

RSTP is able to interoperate with legacy STP protocols. However, it is important to note that the inherent fast convergence benefits of 802.1w are lost when it interacts with legacy bridges.

Each port maintains a variable that defines the protocol to run on the corresponding segment. A migration delay timer of three seconds also starts when the port comes up. When this timer runs, the current STP or RSTP mode associated to the port is locked. As soon as the migration delay expires, the port adapts to the mode that corresponds to the next BPDU it receives. If the port changes its mode of operation as a result of a BPDU received, the migration delay restarts. This limits the possible mode change frequency.

146-r.gif

For instance, suppose Bridges A and B in the preceding figure both run RSTP, with Switch A designated for the segment. A legacy STP Bridge C is introduced on this link. As 802.1D bridges ignore RSTP BPDUs and drop them, C believes there are no other bridges on the segment and starts to send its inferior 802.1D-format BPDUs. Switch A receives these BPDUs and, after twice hello-time seconds maximum, changes its mode to 802.1D on that port only. As a result, C now understands the BPDUs of Switch A and accepts A as the designated bridge for that segment.

146-s.gif

Notice in this particular case, if Bridge C is removed, Bridge A runs in STP mode on that port even though it is able to work more efficiently in RSTP mode with its unique neighbor B. This is because A does not know Bridge C is removed from the segment. For this particular (rare) case, user intervention is required in order to restart the protocol detection of the port manually.

When a port is in 802.1D compatibility mode, it is also able to handle topology change notification (TCN) BPDUs, and BPDUs with TC or TCA bit set.

 

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml