CCIE R&S Advanced Technologies Class v4.5 - Establishing BGP Peerings, EBGP Multihop, BGP Neighbor Disable Connected Check, BGP TTL Security

Transcript

1	Introduction	0h 43m
2	Using the Cisco Documentation	0h 52m
3	Ethernet Overview, Layer 2 Switchports, Trunking, ISL, 802.1q, DTP	0h 47m
4	VTP, VTP Authentication, VTP Pruning	1h 02m
5	VTP Prune Eligible List, VTP Transparent, VTP Troubleshooting, Trunk Allowed List, Extended VLANs	0h 48m
6	VLAN and VTP Review	0h 19m
7	SVIs, Native Routed Interfaces, Router-on-a-Stick	0h 46m
8	Layer 2 EtherChannel, EtherChannel Load Balancing, Layer 3 EtherChannel	0h 57m
9	802.1q Tunneling, Layer 2 Protocol Tunneling, EtherChannel over 802.1q Tunneling	1h 03m
10	STP Root Bridge Election, STP Root Port Election, STP Designated Port Election, STP Priority, STP Cost, STP Port-Priority	1h 46m
11	STP Review	0h 12m
12	STP Timers, STP PortFast	0h 34m
13	STP UplinkFast	0h 11m
14	STP BackboneFast	0h 12m
15	STP BPDU Filter	0h 13m
16	STP BPDU Guard	0h 11m
17	STP Root Guard	0h 11m
18	STP Loop Guard, Unidirectional Link Detection (UDLD)	0h 11m
19	Multiple Spanning-Tree Protocol (MST)	0h 40m
20	Rapid Spanning-Tree Protocol (RSTP), Rapid-PVST	0h 18m
21	MST with Multiple Regions	0h 33m
22	Flex Links	0h 16m
23	Frame Relay	0h 39m
24	Frame Relay Configuration Part 1	0h 34m
25	Frame Relay Configuration Part 2	0h 41m
26	Frame Relay Switching	0h 27m
27	Back-to-Back Frame Relay	0h 08m
28	Frame-Relay End-to-End Keepalives	0h 18m
29	PPP, PPP PAP Authentication, PPP CHAP Authentication	0h 59m
30	PPPoFR, PPPoE	0h 40m
31	Transparent Bridging, IRB	0h 32m
32	Fallback Bridging	0h 14m
33	IP Routing Overview, Switching Paths, Static Routing	0h 42m
34	Static Routing Examples	0h 25m
35	IP Default-Gateway, IP Default-Network	0h 14m
36	On-Demand Routing (ODR)	0h 07m
37	Floating Static Routes	0h 10m
38	Backup Interface	0h 29m
39	Enhanced Object Tracking, IP SLA, Reliable Static Routing	0h 21m
40	Policy Routing	0h 43m
41	GRE Tunneling, GRE Recursive Routing Errors	0h 27m
42	Reliable Backup Interface with GRE	0h 25m
43	RIP Overview, RIP Versions, RIP Auto-Summary	0h 48m
44	RIP Split-Horizon, RIP Timers	0h 22m
45	RIP Broadcast Updates, IP Directed Broadcast, IP Broadcast-Address, Smurf Attacks, Fraggle Attacks	0h 16m
46	RIP Unicast Updates	0h 03m
47	RIP Offset-List	0h 18m
48	RIP Authentication	0h 11m
49	RIP Summarization	0h 10m
50	Prefix-Lists, RIP Distribute-List Filtering, RIP Administrative Distance Filtering	0h 48m
51	RIP Default Routing, RIP Conditional Default Routing	0h 18m
52	RIP Triggered, RIP Validate Update Source,	0h 12m
53	EIGRP Overview	0h 29m
54	EIGRP Auto-Summary	0h 07m
55	EIGRP Split-Horizon	0h 11m
56	EIGRP Update Types, EIGRP Neighbor, EIGRP Passive-Interface	0h 24m
57	EIGRP Hello-Interval, EIGRP Hold-Time	0h 05m
58	EIGRP Authentication	0h 11m
59	EIGRP Time Based Authentication	0h 25m
60	EIGRP Path Selection, EIGRP Metric Weights, EIGRP Traffic Engineering	0h 47m
61	EIGRP Unequal Cost Load Balancing, EIGRP Variance	0h 19m
62	EIGRP QUERY, EIGRP Summarization, EIGRP Leak-Map	0h 28m
63	EIGRP Stub Router Advertisement	0h 22m
64	EIGRP Default Routing	0h 13m
65	EIGRP Route Filtering	0h 11m
66	EIGRP Router-ID	0h 07m
67	Miscellaneous EIGRP Features	0h 02m
68	OSPF Overview	0h 27m
69	Establishing OSPF Adjacencies, Understanding the OSPF Database	0h 43m
70	OSPF Network Type Broadcast, OSPF DR/BDR Election, OSPF over NBMA, OSPF Network Type Non-Broadcast and Point-to-Multipoint	0h 56m
71	OSPF Network Type Point-to-Point, OSPF Network Type Mismatch	0h 13m
72	OSPF Network Type Point-to-Multipoint Non-Broadcast, OSPF Per Neighbor Cost	0h 17m
73	OSPF Network Type Loopback	0h 02m
74	OSPF Path Selection	0h 27m
75	OSPF Convergence Timers	0h 09m
76	OSPF Authentication	0h 12m
77	OSPF Summarization	0h 32m
78	OSPF Stub Areas, OSPF Totally Stubby Areas, OSPF NSSAs, OSPF Totally NSSAs	0h 40m
79	Controlling OSPF NSSA Redistribution	0h 02m
80	OSPF Type 7 to 5 Translator Election, OSPF LSA Type 3 Filter, OSPF Forwarding Address Suppression	0h 24m
81	Route Redistribution Overview	0h 36m
82	Route Redistribution Configuration & Verification, Connected Redistribution	0h 22m
83	OSPF External Path Selection, TCL PING Scripting	0h 33m
84	Routing Loops Overview, EIGRP Route Loop Prevention	0h 55m
85	Metric Based Routing Loops, Route Tagging	0h 46m
86	Administrative Distance Based Routing Loops, Debug IP Routing, IP Route Profile	0h 58m
87	BGP Overview, BGP Peering Types	0h 51m
88	Establishing BGP Peerings, EBGP Multihop, BGP Neighbor Disable Connected Check, BGP TTL Security	0h 49m
89	BGP 4-Byte ASNs	0h 20m
90	BGP Local AS, BGP Peer Groups	0h 30m
91	BGP Next-Hop Self, BGP Next-Hop Processing	0h 30m
92	BGP Route Reflectors	0h 37m
93	Large Scale BGP Route Reflectors with Clusters	0h 34m
94	BGP Confederation	0h 37m
95	BGP NLRI Advertisements, BGP Network Statement, BGP Redistribution	0h 43m
96	BGP Aggregation, BGP Aggregation & Summary-Only, BGP Aggregation & Unsuppress-Map	0h 46m
97	BGP Origin, BGP Aggregation & AS-Set, BGP Aggregation & Advertise-Map	0h 22m
98	BGP Conditional Route Injection	0h 21m
99	BGP Bestpath Selection, BGP Multipath, BGP Weight	0h 53m
100	BGP Local Preference, BGP Local Preference and Communities, BGP AS-Path Prepending,	0h 30m
101	BGP MED, BGP MED Missing As Worst, BGP Deterministic MED	0h 17m
102	BGP Communites, BGP Regular Expressions	0h 43m
103	BGP Filtering, BGP Convergence Timers, BGP Default Routing, Miscellaneous BGP Features	0h 24m
104	MPLS Overview, MPLS Label Distribution Protocol (LDP)	1h 05m
105	MPLS Tunnels, MPLS Penultimate Hop Popping (PHP)	0h 40m
106	MPLS Layer 3 VPNs Overview, VRF Lite	0h 36m
107	MPLS Layer 3 VPNs and VPNv4 BGP	1h 08m
108	MPLS Layer 3 VPN Verification & Troubleshooting	0h 49m
109	MPLS Layer 3 VPN OSPF PE-CE Routing Overview	0h 06m
110	MPLS Layer 3 VPN OSPF PE-CE Routing Path Selection & Sham-Links	2h 01m
111	MPLS Layer 3 VPN OSPF PE-CE Routing Loop Prevention & Down-Bit, OSPF Capability VRF-Lite	0h 40m
112	IPv6 Overview, IPv6 ICMPv6 ND, IPv6 over NBMA	0h 44m
113	IPv6 Routing Overview, IPv6 Static Routing	0h 28m
114	IPv6 RIPng	0h 20m
115	IPv6 EIGRPv6	0h 09m
116	IPv6 OSPFv3	0h 31m
117	MP-BGP for IPv6	0h 26m
118	IPv6 Tunneling	1h 13m
119	Multicast Overview, IGMP	0h 34m
120	PIM Overview	0h 18m
121	PIM Dense Mode	1h 03m
122	PIM Sparse Mode	0h 30m
123	PIM Sparse Mode Configuration	0h 36m
124	PIM Sparse Mode RPF & RP Troubleshooting	0h 27m
125	Auto-RP, Multicast over GRE Tunnels	0h 53m
126	Bootstrap Router (BSR), Bidirectional PIM, Source Specific Multicast (SSM)	0h 40m
127	MSDP, Anycast RP	0h 27m
128	IPv6 Multicast Routing	0h 24m
129	QoS Overview, IntServ QoS, DiffServ QoS, IP Precedence, DSCP, MQC, HQF	0h 41m
130	MQC Classification	0h 44m
131	FIFO, FQ, WFQ, CBWFQ, HQF	0h 50m
132	LLQ	0h 23m
133	WRED	0h 31m
134	Traffic Shaping, Traffic Policing	0h 40m
135	Frame Relay Traffic Shaping (FRTS)	0h 33m
136	RSVP	0h 07m
137	Catalyst 3560 QoS	1h 00m
138	IOS Security Overview, Access Lists (ACLs)	0h 58m
139	Time Based ACLs, Dynamic ACLs	0h 33m
140	Reflexive ACLs	0h 21m
141	TCP Intercept, Content Based Access Control (CBAC)	0h 34m
142	Zone Based Policy Firewall (ZBPF)	1h 09m
143	AAA, Local Authentication, Local Authorization, Role Based CLI Access	0h 43m
144	Port Security, Static CAM Entries, Storm Control, 802.1X Authentication, PACLs, RACLs, VLAN Access Maps (VACLs)	0h 48m
145	DHCP Snooping, Dynamic ARP Inspection (DAI), IP Source Guard	0h 12m
146	Protected Ports, Private VLANs	0h 25m
147	IP Services Overview, HSRP	1h 10m
148	VRRP, GLBP	0h 28m
149	NAT	0h 42m
150	DHCP, DNS	0h 30m
151	NetFlow	0h 09m
152	WCCP, Miscellaneous IP Services	0h 06m
153	System Management Overview, NTP, NTP Authentication	0h 24m
154	SNMP, RMON	0h 38m
155	Syslog, Telnet, SSH, Banners	0h 21m
156	EEM Scripting, Miscellaneous System Management	0h 26m
Total Duration		81h 42m

Slides - Diagrams

Slides - Introduction

Slides - Ethernet Switching

Slides - Advanced Ethernet Switching

Slides - Frame Relay

Slides - PPP

Slides - Transport Bridging

Slides - Redistribution

Slides - IOS Security

Slides - Layer 2 Security

Slides - IP Services

Slides - System Management

0:00:14	Continuing on with our discussion of BGP here.
0:00:17	We talked about the general attributes of the protocol.
0:00:20	What are the different requirements for establishing the peerings?
0:00:23	Whether they're IBGP or EBGP
0:00:26	and some of the different attributes that are going to apply
0:00:28	in the differences of those type of peerings.
0:00:31	So, next, we're gonna take a look at the command line.
0:00:34	Go through some examples of actually establishing the peerings,
0:00:38	look at the different verifications with the show commands and debug commands
0:00:41	to figure out what are the potential problem issues that we could run into
0:00:45	when we are actually trying to establish the adjacencies.
0:00:49	Now, again, the keypoint in our first step, when we're defining the neighbors,
0:00:53	to actually establish the BGP peering,
0:00:56	is that this command has dual functionality.
0:00:59	It means that we're gonna start listening for a BGP connection to come from the remote address.
0:01:05	And also that we are going to initiate a session that is going to the remote address.
0:01:10	With these two attributes, both the TCP client and the TCP server have to agree
0:01:16	on where the BGP seesion is going and where the BGP session is coming from.
0:01:23	So, let's take a look at our topology here.
0:01:26	Where internal to the network, right now I have everyone running IGP.
0:01:32	Where EIGRP AS 100 is running on all of the transit links
0:01:36	and advertising their loopback interfaces into the topology.
0:01:40	So, at this point, if we were to look at anyone in the network, let's say switch 4 for example,
0:01:46	and look at the Show IP Route,
0:01:49	we should see essentially any destination that is internal to our network,
0:01:54	we should have reachability to it.
0:01:56	So, the loopback interface of router 1,
0:01:59	of 150.28.1.1,
0:02:06	of router 2, of router 3, etc.
0:02:10	So, the first requirement of BGP,
0:02:13	is that we always have that underlying IGP transport.
0:02:17	If we cannot establish basic IGP reachability,
0:02:20	then it implies we cannot establish the TCP session
0:02:23	and we cannot do any of other options beyond that in BGP.
0:02:28	So, first, let's look at doing some peerings between directly conencted neighbors.
0:02:32	We'll look at establishing a session between router 4 and router 5.
0:02:38	Where there gonna be in separate autonomous system.
0:02:41	So, we'll say that router 5 is simply an AS 5.
0:02:43	Router 4 is an AS 4.
0:02:47	At this point, we have two directly connected interfaces between them.
0:02:51	One of them is the frame-relay interface. One of them is this point-to-point link.
0:02:57	So, if we were to look at router 4, and look at the Show IP Route Connected,
0:03:03	the two links between them are 155.28.0, weher router 5 is .5
0:03:10	and the 45 network where router 5 is also .5
0:03:17	So, before we actually enable the BGP process,
0:03:20	I'm gonna turn a couple of different debugs on here.
0:03:22	One of them is gonna be to look at the actual BGP peering messages.
0:03:28	And the other one is a low level debug for the actual IP transport.
0:03:33	If we look at the Show IP Protocols,
0:03:36	right now, I'm using EIGRP AS 100 as the IGP for transport.
0:03:42	Now, what I'm gonna do here to look at the BGP packet formats
0:03:47	but not get the EIGRP once in the way,
0:03:50	when I do the debug, I'm gonna filter to specify I do not want to debug EIGRP.
0:03:56	I essentially only want to debug the BGP packets.
0:04:01	So, to do this, I'm gonna create an extended access list.
0:04:03	I'll say Access List 100 is going to deny EIGRP.
0:04:10	And then Permit anything else.
0:04:14	So, this would be any other IP protocol number whether it's ICMP or TCP or UDP,
0:04:20	this access list is gonna match it as long as it's not protocol number 88, which is EIGRP.
0:04:27	Then we're gonna look at the debug IP packet detail.
0:04:30	But filter this through access list 100.
0:04:35	So, now, on this output, we should not see any of our EIGRP hellos or any of our actual EIGRP updates.
0:04:42	But if I were to send a ping to router 5, we should see this output in the debug.
0:04:49	Because this is not protocol 88.
0:04:52	Now, you can see with just those five pings, debug IP Packet Detail is gonna generate a lot of information.
0:04:58	So, normally if you're gonna look at this debug,
0:05:01	you would not wanna send it to the console,
0:05:03	you would wanna send it to the log buffer or to like a remote syslog server.
0:05:09	But in our case, since I know there's not a lot of traffic in the network to begin with,
0:05:12	then we're just gonna look at these from the console.
0:05:16	Now, also, to make the debug a little bit clear, I'm gonna remove the time stamping from all the routers.
0:05:21	Because that's gonna take up a bunch of the lines on the output.
0:05:25	So,from the access server, i'll send to all the routers, No Service Time Stamps.
0:05:33	Which is going to affect the debug messages that are coming out.
0:05:40	So, now again on router 4, if I were to send a ping
0:05:43	to router 5 and let's say just one packet.
0:05:48	We can see even just for one packet, since we're looking at the detail debug,
0:05:51	it's a lot of information that's coming up with the output.
0:05:56	Now, in addition to this, we're gonna look at the debug IP BGP.
0:06:00	Which essentially is all of the debugs for that particular address family,
0:06:06	which is IP version 4 unicast.
0:06:10	Now, the difference in the address families, we'll talk about that in a little bit later, sections...
0:06:14	when we get to multiplecast IPv6 rouiting. And then also for MPLS routing.
0:06:23	Now, we could see from the output on router 4 here,
0:06:26	that there were some packets received in
0:06:29	from the address 204.12.28.254.
0:06:38	It says that the packet was TCP.
0:06:43	The source port was 16119, destination port was 179.
0:06:50	And the type of packet was a SYN.
0:06:54	Now, we know TCP 179 is BGP. So, what this essentially means
0:06:59	is that there's some neighbor on our connected link,
0:07:02	which in this case is BB3.
0:07:05	It's trying to establish BGP peering with us.
0:07:08	Now, since I don't have the BGP process configured,
0:07:13	when the BB3 sends those request to start the TCP session,
0:07:19	router 4 is gonna reply back with a reset.
0:07:22	It's saying that either I'm not running BGP
0:07:26	or I don't have a particular peering that is associated with your address.
0:07:34	Now, if we were to configure a neighbor statement under BGP process
0:07:38	for that particular address, 204.12.28.254,
0:07:42	then router 4 would be listening for the session.
0:07:45	But the keypoint is that by default, BGP is not dynamic
0:07:49	in the term that it cannot learn its peers automatically.
0:07:53	We have to specify these manually with the neighbor statement.
0:07:59	So, next under global config, we'll start the BGP process,
0:08:04	we'll say this is BGP AS 4.
0:08:06	And we could also see based on IOS version of router 4,
0:08:10	it does support the 4-byte autonomous system.
0:08:13	So, we'll come back to that a little bit later and see what happens when we have the 4-byte AS
0:08:18	plus the 2-byte AS interacting with each other in the topology.
0:08:24	Now, before I actually configure the peering, I'm gonna go to router 5.
0:08:28	And debug IP BGP.
0:08:31	And then do the same access list debug wher I'm denying EIGRP
0:08:37	and then permiting everything else. So, access list 100 Permit IP Any Any,
0:08:43	after the Deny EIGRP. Then I'll debug IP Packet detail using access list 100.
0:08:52	Now, on router 4, I'm gonna specify the neighbor statement that's going to...
0:08:58	Let's say the frame-relay interface of router 5. So, 155.28.0.5
0:09:04	And router 5 is gonna be in autonomous system number 5.
0:09:09	If we now look at router 5, we should see that there's a TCP SYN packet coming in from router 4.
0:09:19	It's going to port 179. This is router 4 trying to start the session.
0:09:26	Since router 5 does not have the neighbor statement configured on the way back,
0:09:29	it's replying with the reset, saying, "I don't have the session configured."
0:09:35	Which is what we would expect because router 5's not configured for BGP yet.
0:09:41	So, now, let's go onto the process. We'll say router BGP 5.
0:09:46	And router 5 is gonna peer with router 4.
0:09:50	But in this case, we're gonna peer with the point-to-point interface, not the frame-relay.
0:09:58	So, the remote AS is 4.
0:10:07	So, in this type of case, what we would see where router 4 is configured to peer with 5 via the frame-relay.
0:10:16	And 5 is configured to peer with router 4 via the point-to-point link,
0:10:20	since the TCP server and the TCP client do not agree on where the session is coming from and going to,
0:10:28	when the initial BGP open message is sent,
0:10:31	the other neighbor's gonna reset the connection.
0:10:35	And we see this from router 5's output that I tried to send from myself going to port 179
0:10:44	the first portion of the three-way handshake. So, I'm trying to open the TCP session.
0:10:49	Then router 4 replies back
0:10:52	with the TCP reset saying, "I don't have a peering configured for that particular address."
0:10:58	Which is the 45.5 address.
0:11:03	If we look at it in the reverse path,
0:11:06	likewise router 4 via the frame-relay is trying to initiate the session to 5.
0:11:14	Then router 5 is reseting this saying that I don't have a peer
0:11:18	that is configured for that particular address.
0:11:25	So, this is why it's very important in the BGP network
0:11:29	to figure out what is the route between the two neighbors
0:11:34	before we go to establish the peering.
0:11:37	Now, between these two routers, it's pretty obvious to tell what it is.
0:11:41	Because they're directly connected on both of those links.
0:11:44	We know that if router 4 is gonna route to router 5's frame-relay interface,
0:11:48	router 4 is gonna use disconnected link to get there.
0:11:51	Then likewise on router 5, if I'm gonna get to the address of serial 0/1/0 on router 4,
0:11:57	I'm gonna use my local interface to get there.
0:12:00	Simply because those are connected routes.
0:12:03	Now, where this is a little less obvious,
0:12:06	is where the routers are more than one hop away from each other.
0:12:10	Then it is going to depend on the routing table
0:12:13	to determine whether the session will or will not be allowed.
0:12:19	So, now, let's say for example that router 5 is trying to peer with router 6.
0:12:26	And router 6 is in AS 6, router 5 is in AS 5. So, this is a multihop EBGP peering.
0:12:34	When router 5 configures the neighbor statement, let's say that we point it at the VLAN 67 interface,
0:12:42	when router 6 configures the neighbor statement, it points it at the point-to-point -link to router 5.
0:12:50	So, now we would need to consider when router 5 generates the TCP packet to begin with
0:12:56	that is going to router 6.
0:12:58	What is the local interface that I would use in order to reach that particular destination?
0:13:06	Now, we can tell this on router 5 if we were to look at the routing table.
0:13:10	If I were to say, Show IP Route for 155.28.67.6,
0:13:16	it says, "My particular route to that detination is via serial 0/0/0."
0:13:25	Now, this essentially means that whatever IP address I have assigned on that interface,
0:13:29	that's gonna be the source of the packet when it goes out to router 6.
0:13:34	Now, on router 6, we can't necessarily guarantee
0:13:38	that the return path is gonna be the same via that interface.
0:13:42	So, if we look at the Show IP Route for 155.28.45.5,
0:13:50	or the 0.5,
0:13:54	notice that for both of these addresses on router 5,
0:13:59	router 6 says that I would use Fast Ethernet 0/0.146 in order to get there.
0:14:08	So, from router 6's perspective,
0:14:11	if we were to look at the Show Run Interface Fast Ethernet 0/0.146,
0:14:17	each BGP update is gonna come for the address 155.28.146.6
0:14:24	If this does not match with the neighbor statement that router 5 has configured,
0:14:30	the TCP session will not establish.
0:14:33	And you could think that this is kind of a security mechanism for BGP,
0:14:37	where essentially the two neighbors, they should already know what address is they're gonna peer with.
0:14:42	If someone is trying to spoof the BGP connection,
0:14:45	maybe they're sending the set-up message to some random address on the router.
0:14:49	We would ideally want to deny that connection.
0:14:53	So, BGP does not run in promiscuous mode by default.
0:14:56	Like OSPF or EIGRP does.
0:15:01	Now, there's a simple way that we could get around with this design
0:15:04	is simply to tell the routers what is the address we wanna use
0:15:08	when we're sending packets to that neighbor.
0:15:10	And this is what the update source command is designed to do.
0:15:14	So, in any situation that we are not peering
0:15:18	over a directly connected link between the neighbors,
0:15:21	we should manually specify where the packet is coming from
0:15:25	so the remote end is thengoing to agree with that.
0:15:30	You'll see that the vast majority of real design cases for this,
0:15:34	will be that the update source is gonna be a loopback interface.
0:15:38	The reason behind this is, let's say between router 5 and router 6,
0:15:42	if I'm advertising my loopback into IGP,
0:15:46	then it really doesn't matter what physical link I'm using to route
0:15:50	in order to get between router 5 and router 6.
0:15:53	As long as there is one physical path available,
0:15:56	then I should be able to reach, from 6, the loopback of 5.
0:16:00	And from 5, the loopback of 6.
0:16:03	So, as long as they're both agreeing onthe TCP session,
0:16:06	it doesn't actually matter, the path that the control plane traffic is routed.
0:16:10	As long as it gets to them and the TTL is not expired in the transit path,
0:16:14	that's really all that we care about.
0:16:18	Now, for the peering between router 4 and router 5,
0:16:22	We could manually change this on router 5 to say that
0:16:24	to get to that address, the serial 0/1/0, the update source would be the frame-relay.
0:16:33	In that case, we would see that at least in one direction of the session,
0:16:38	the client agrees on what the server as to what the address is.
0:16:42	But typically, you wouldn't want to do this implementation.
0:16:45	it's kind of over complicated the issue.
0:16:48	So, what I mean by this, I could go to router 5
0:16:52	and under the BGP process,
0:16:56	we'll say that for this particular neighbor,
0:16:59	my update source is serial 0/0/0.
0:17:05	Now, if we were to look at router 4 and look at the output from the debug,
0:17:13	we're gonna see both the IP packet debug and the actual BGP peering state machine output.
0:17:20	Where router 4 is saying that I sent a packet, let's see, let's scroll up a little bit further.
0:17:35	It's gonna be right here as the start of the session.
0:17:37	So, it says, a packet came in from router 5.
0:17:43	It's going to one of my addresses.
0:17:46	Now, from router 4's perspective, it doesn't really care where the packet is going.
0:17:50	It's more concerned about where the packet came from.
0:17:54	So, the packet came from 0.5, which matches one of the neighbor statements that I have configured.
0:18:01	We see that this is going to port 179. So, it means that router 5 here is the client.
0:18:08	because the client's communication is going to 179,
0:18:14	where the server's communication is gonna be sourced form 179.
0:18:18	So, we see the reply from router 4.
0:18:21	It's coming from 179 going back to router 5.
0:18:24	This is the second portion of the handshake.
0:18:28	Router 4's acknowledging 5, "I got your packet."
0:18:31	Sending the SYN, saying, "I also wanna open the session."
0:18:35	Then we should see the final portion that is completely opening the session.
0:18:40	Which is router 5's acknowledgement to router 4,
0:18:42	saying, "We're gonna start a TCP session on port 179."
0:18:45	And this is the particular random port that we're using. 52798.
0:18:52	So, we see, once we get past the actual TCP transport establishment,
0:18:57	then we actually go through the BGP state machine.
0:19:00	Where it says that now, we're trying to connect.
0:19:04	We received an open message from router 5.
0:19:07	This is where the routers go to the actual negotiation of what are the options for the adjacency.
0:19:13	So, router 5 is saying, "I'm running BGP version 4."
0:19:16	This is the whole time that I want to have configured.
0:19:20	Then it says, "We are negotiating a capability."
0:19:26	Which is for address family identifier 1 and sub address identifier 1.
0:19:33	Which essentially is IP version 4 unicast routing.
0:19:39	So, router 4 is telling router 5 and they're agreeing on this that both of them want to run regular IP routing.
0:19:46	Which is gonna be the default.
0:19:48	Okay, we'll also see some of these optional capabilities that are there by default. The route refresh.
0:19:53	Which we'll see later as used to ask for or send a triggered updates in BGP,
0:19:59	without having to destroy the TCP session and then rebuild the full adjacency.
0:20:06	We'll also see, there's some other capabilities they negotiated here.
0:20:09	One is gonna be the 4 byte autonomous system number.
0:20:15	Then, we go from open sent to open confirm basically saying that "I agree with whatever options that you wanted."
0:20:23	So here, before we get to open confirm,
0:20:26	this is where we could potentially see a mis-negotiation in the parameters.
0:20:31	So, if router 5 was trying to run...
0:20:33	IPv6 routing, where IP...
0:20:38	Where the other router is trying to run version 4 routing,
0:20:42	then, instead of going to open confirm, we would see a notification message being generated.
0:20:47	So, notification means that they could not exchange
0:20:50	a set of capabilities where they both agreed on, and they're having to reset the session.
0:20:55	So, it could be something as simple as the AS number is wrong.
0:20:59	Or you're trying to route IPv6 while I'm trying to route IPv4.
0:21:05	Okay, then, we actually go to the normal data exchange,
0:21:09	this is where we're sending the update messages.
0:21:11	Okay, at this point, we're not actually advertising anything in the BGP.
0:21:15	So eventually, we'll see that the session goes to...
0:21:19	fully-established, which is here.
0:21:23	So, if we're not doing any debugs,
0:21:25	Once the peering is working,
0:21:26	we should get this final log message that says, "BGP 5 adjancency changed.
0:21:31	The neighbor is off."
0:21:33	Okay, not that we're running BGP Version 5,
0:21:36	this is a level 5 logging message.
0:21:40	So, if we were logging level 5 or above, then, we should see this particular log.
0:21:48	So, if we look at the configurations on both of them, let's say Show Run Section Router BGP.
0:21:59	We technically can do this configuration,
0:22:02	where they're peering with different physical interfaces.
0:22:05	So, router 5 is peering with 4's point-to-point serial,
0:22:09	but it's sending its updates from the frame-relay.
0:22:12	As long as router 4 agrees that this is where the session is supposed to come from,
0:22:17	then, the peering is gonna work.
0:22:22	Now, what would be the disadvantage of this type of design?
0:22:27	Where router 5 is peering with the point-to-point link.
0:22:32	4 is peering with the frame-relay,
0:22:35	and router 5 is sourcing its updates from the frame-relay.
0:22:44	The problem is gonna be that if either of these physical links goes down,
0:22:48	then, the BGP control plane is gonna be lost.
0:22:51	So, even though there may be multiple routes between the neighbors,
0:22:54	BGP would not be able to take advantage of that
0:22:57	if the peering is based on a physical interface
0:23:02	that has the IP address assigned.
0:23:05	So, in the vast majority of cases, you'll see that if the BGP peers have multiple IGP routes between them,
0:23:12	or multiple IGP paths between them,
0:23:14	then, it would make more sense to source the connection from the loopback interface.
0:23:20	So, let's undo...
0:23:22	the neighbor relationship we have here.
0:23:24	So, on router 4, let's just say No Router BGP 4.
0:23:29	And on router 5, we'll say No Router BGP 5.
0:23:34	Okay, we'll look at those same debugs though. We'll Debug IP Packet Detail 100.
0:23:38	And Debug IP BGP.
0:23:44	Next, on router 5, we're going to start the process again.
0:23:49	I'm gonna configure a peering with the loopback address of router 4,
0:23:53	which is 150.28.4.4.
0:23:57	We'll say, they are in AS number 4.
0:24:02	And I am going to source my packets
0:24:05	from my own loopback zero interface.
0:24:11	Then, router 4 likewise is gonna do the same thing. So, Router BGP 4.
0:24:15	I'm peering with router 5's loopback.
0:24:20	And my update source is loopback zero.
0:24:28	Debug IP Packet Detail 100, and Debug IP BGP.
0:24:35	Now, before we can establish the TCP session,
0:24:38	we're assuming here that there is reachability between those two loopbacks.
0:24:41	So, it may make sense to test this if we ping 150.28.5.5,
0:24:47	and source this from my own loopback zero.
0:24:50	I know that there is transport between the two addresses.
0:24:55	Okay, we'll see, the Debug IP Packet Output is a lot,
0:24:58	but there was a correct response in from the ICMPs.
0:25:03	Okay, as we see, there's the echo reply coming back from router 5.
0:25:07	If we look at the Debug Output on router 5 though,
0:25:11	we'll see that there is nothing here related to the BGP session
0:25:16	either trying to be established from router 5,
0:25:20	or being sent to router 5.
0:25:26	The reason why...
0:25:28	is that since these are EBGP peers,
0:25:32	router 5 is gonna say, what is my route to get to 150.28.4.4?
0:25:41	Since this destination is an EBGP peer,
0:25:45	and the route is not via a connected interface,
0:25:49	so, I'm learning it via IGP. I'm not learning it via connected link.
0:25:54	Then, neither of the processes are going to establish by default.
0:25:58	So essentially, no one is gonna send the initial TCP syn.
0:26:02	This is what...
0:26:04	the neighbor...
0:26:07	Disable Connected Check would be for.
0:26:12	Disable Connected Check.
0:26:13	So technically, router 4 and router 5,
0:26:16	they are not more than one hop away.
0:26:22	Because if we were to do a traceroute to 150...
0:26:28	150.28.4.4,
0:26:32	we see, it's only one hop away.
0:26:33	So, regardless which interface we go out,
0:26:36	whether it's the point-to-point link or the frame-relay, it's only one hop away.
0:26:40	But router 5 right now has been configured to disable that connected check,
0:26:44	where router 4 has not.
0:26:47	So, router 4 is receiving the packet in.
0:26:49	It's saying, "To get to you, you're not via connected interface.
0:26:53	So, I'm sending a TCP reset instead of agreeing on the session."
0:26:59	So essentially, both of the neighbors would have to agree on this.
0:27:02	If we say under the BGP process
0:27:04	that for this neighbor,
0:27:05	we want to disable the connected check.
0:27:18	So we see, we go to the full capability exchange, now, the neighbor is up.
0:27:23	If we now look at the output of the Show IP BGP Neighbor,
0:27:28	this is gonna give us all the detail about that particular peering.
0:27:33	So, to start, it says, "This is the neighbor's address that I'm actually peering with."
0:27:38	We're both running BGP Version 4.
0:27:41	The router ID of them is 150.28.5.5.
0:27:46	Now, we'll see later, both in the BGP best path selection,
0:27:49	and some of the loop prevention mechanisms,
0:27:51	BGP will be using the router ID
0:27:53	to figure out if an update was locally originated from that local device.
0:28:02	Next, it says that the hold time is 180 seconds, the keepalive interval is 60 seconds.
0:28:08	So, this is basically like the hello and dead timer for OSPF.
0:28:14	Now, with BGP,
0:28:16	this value does not have to match in the configuration.
0:28:20	It will be automatically negotiated down
0:28:22	to whatever the lower value is
0:28:24	that the neighbor is requesting.
0:28:27	So on router 4, if I were to set the timer values lower,
0:28:31	let's say 5 seconds for keepalive and 15 seconds for the hold time,
0:28:34	if I were then to clear the TCP session
0:28:37	into a new re-establishment of the peering,
0:28:41	then, we would see that both of them are gonna use those lower negotiated value.
0:28:47	Next, it says, the neighbor capabilities, we have route refresh advertised and received.
0:28:52	We'll see later again, this is gonna be used for sending and requesting triggered updates.
0:28:58	The new autonomous system number capability, that's gonna be for the 4 byte AS number.
0:29:03	Address family IPv4 unicast. So, this means we're running normal IP routing over this session.
0:29:09	If we were running IPv6, or IPv4 multicast, or MPLS,
0:29:14	we should see under the neighbor capabilities
0:29:17	they have both advertised and received that particular attribute.
0:29:23	If it says IPv4 is advertised but not received,
0:29:26	it means they're not both agreeing that they're gonna run that particular type of routing.
0:29:33	So, most of the rest of the output here will be things that...
0:29:36	you should need to reference most of the time.
0:29:40	Things about the statistics about how many prefix are being advertised,
0:29:43	withdrawn, how many are being used for the best paths.
0:29:47	One other thing we may want to know is...
0:29:51	what is the Time To Live,
0:29:55	who is the server and who is the client.
0:30:00	So, from router 4's perspective, it is the server,
0:30:04	because it is sourcing its traffic from 179,
0:30:08	and the traffic is going to 47909.
0:30:12	If we were to look at this on router 5, it should be the opposite.
0:30:16	Router 5, if we Show IP BGP Neighbor,
0:30:24	router 5 says, "The local port is that random one, 47909.
0:30:28	The foreign port, or the remote port,
0:30:31	the destination port is 179."
0:30:36	Now, in reality, it's not gonna matter on who is the client and who is the server
0:30:41	as long as there's no filtering on port 179.
0:30:46	The actual device that becomes the client is generally just the person who initiates the session first.
0:30:53	It's only gonna go to the router ID
0:30:55	if both of them happened to send the TCP syn at the same exact time.
0:31:00	So, you could technically run into some advanced designs where
0:31:03	maybe one routers behind network address translation,
0:31:06	then, it would matter on who is the client and who is the server
0:31:10	if an outbound connection is allowed,
0:31:12	but an unsolicited inbound connection is not.
0:31:16	So, that would be the same like if we're going through some sort of active firewall.
0:31:25	There's a question, "What is the incoming TTL here?"
0:31:29	That's actually gonna be related to the next feature we're gonna look at,
0:31:32	which is the TTL Security feature for BGP.
0:31:38	Now, as we know, the peering between these two neighbor is EBGP.
0:31:43	So, it means the Time To Live is 1, between them by default.
0:31:48	Now, let's say that I were to do a peering between router 5 and router 6.
0:31:54	So, router 6, we'll say it's an AS 6.
0:31:56	4 is in 4.
0:31:58	5 is in 5.
0:32:00	So, from 6 and 5's perspective, they're gonna be multiple hops away.
0:32:04	Which is fine as long as you tell the routers that you need to increase the Time To Live
0:32:08	for that particular session.
0:32:12	So, let's go to router 5,
0:32:14	and under the BGP process,
0:32:17	we'll say, Neighbor 150.28.6.6. Remote AS 6.
0:32:24	My update...
0:32:26	source is loopback zero.
0:32:29	And I need to increase the Time To Live. So, EBGP multi-hop.
0:32:33	And I could give it a value, or I could just use the default, which is 255.
0:32:39	Okay, if we do not configure this command,
0:32:41	it defaults to 1.
0:32:43	So, by specifying EBGP multi-hop, when we look at the running config,
0:32:47	Show Run Section Router BGP.
0:32:50	It says, "Now, the Time To Live is changed to 255."
0:32:54	So essentially, it means it doesn't matter how far away they are,
0:32:57	as long as I can reach them, I'll establish the session.
0:33:01	Now, on router 6, we're basically gonna do the same thing, but it's gonna be on the reverse path.
0:33:07	Now, you'll see with a lot of these BGP configs,
0:33:10	since the syntax is fairly similar,
0:33:14	where the only main difference is that we're changing the addresses.
0:33:17	A lot of times, it makes sense just to do these configs in no path.
0:33:22	This will also make sure
0:33:24	that you're not leaving some sort of key configuration out
0:33:27	like the update source on one side,
0:33:29	or the multi-hop, or whatever other attributes that we want.
0:33:35	So, on router 6, I'll paste the same configuration in,
0:33:39	where the only thing that is changed is the local autonomous system number,
0:33:43	the remote AS number of router 5,
0:33:46	and then, the loopback address of router 5.
0:33:51	From router 6, if we now look at the Show IP BGP Neighbor,
0:34:00	It says that "The neighbor is an external BGP neighbor that may be up to 255 hops away."
0:34:06	So, this is the outgoing Time To Live.
0:34:10	Now, by default, the EBGP multi-hop command
0:34:14	is only gonna control what the TTL value is on your outbound packets.
0:34:21	So technically, router 5 and router 6, they could have different multi-hop values
0:34:25	as long as the packet eventually gets there.
0:34:28	Now, the potential design issue that we could run into though
0:34:32	is that it is possible to spoof a TCP session
0:34:36	if you have some sort of attack that can predict the TCP sequence numbers.
0:34:42	And originally, it was though that predicting the sequence numbers is not feasible,
0:34:46	but some of the attacks fairly recently have shown that it is possible to do that,
0:34:51	and there are attacks that you can use to actually reset a TCP session of BGP on the Internet.
0:34:59	Now, what the implication of that is
0:35:02	is that if I send TCP reset attacks to the transit routers in the Internet,
0:35:06	they're gonna drop their BGP session and then, start dropping old traffic.
0:35:11	So, it's again essentially just a control plane denial of service attack,
0:35:15	where we're trying to tell the router to delete its BGP peerings,
0:35:18	which then means it has no routes.
0:35:21	So, to protect against this,
0:35:24	if router 5 and router 6,
0:35:27	let's assume that they are exactly two hops away from each other.
0:35:32	So, we know that there's only one router between them.
0:35:36	So, when router 5 sends a packet to 4,
0:35:38	4 sends it to 5, of 4 sends it to 6,
0:35:43	when 6 receives the packet in,
0:35:47	we can infer the transit path that the packet followed
0:35:51	if the Time To Live value is 255 minus the number of hops.
0:36:00	So, if this device is suppose to be two hops away,
0:36:04	and we say that the TTL should be at least 253,
0:36:10	this would prevent a case where router 6 connects to router 3,
0:36:15	and then, we go out to the rest of the IP cloud.
0:36:18	It would prevent an unsolicited attack
0:36:21	from coming from someone who is more than two hops away.
0:36:27	So, if we're assuming that this TCP reset attack
0:36:32	is gonna come from some end host in the Internet,
0:36:34	it's very likely that they're gonna be more than two hops away from this particular router.
0:36:39	So, maybe when the packet finally gets to router 6 from the attacker,
0:36:43	maybe the TTL is like 228.
0:36:47	So, router 6 can implement a check
0:36:50	that says, "When I receive the BGP packet in from this neighbor,
0:36:55	check the remaining Time To Live.
0:36:58	If it below a certain threshold, it's possible that that session is trying to be spoofed,
0:37:03	so I'm simply going to deny that packet."
0:37:11	Now, there's a question here, "Doesn't the password already protect against this?"
0:37:16	Technically, it does because for BGP authentication,
0:37:21	it doesn't use its own form of authentication.
0:37:24	Okay, it uses what is defined in TCP option number 19,
0:37:32	which is...
0:37:35	the MD-5 signature.
0:37:39	And this is defined by RFC 2385.
0:37:43	Okay, it says it's a "TCP extension to enhance BGP security."
0:37:47	So, it's essentially just a password that is a MD-5 hash between the neighbors.
0:37:52	The problem with this though
0:37:54	is that everytime the router receives a packet in,
0:38:00	it has to run on MD-5 hash on the header.
0:38:04	So, if we were trying to implement some sort of reset attack,
0:38:07	it's not gonna work, let's say, the attacker is here.
0:38:14	So, the attackers here, they're connected to the IP cloud.
0:38:16	They're multiple hops away from router 6.
0:38:19	If router 6 is doing authentication with router 5,
0:38:23	then, there's no way that they could do a reset attack,
0:38:26	but they can technically do a denial of service attack against the MD-5 process itself.
0:38:33	So, if we figured that the attacker is sending however many packets per second attack,
0:38:39	let's say, 20,000 packets second.
0:38:41	Okay, which is a fairly feasible value that you could be able to forward into the Internet.
0:38:47	If I'm setting 20,000 malformed TCP syn packets per second,
0:38:52	it means that everytime router 6 receives those,
0:38:55	it's gonna have to run the MD-5 hash against it.
0:38:58	So, it's essentially a denial of service against the control plane.
0:39:02	That's not trying to get them to drop the routes,
0:39:05	it's just trying to get their CPU so high that they can't even manage the session to begin with.
0:39:11	So typically, you would implement both of these at the same time.
0:39:16	The password authentication plus the TTL security.
0:39:19	So the, the router says that "If the TTL is lower than the threshold,
0:39:23	I'm not even gonna look at the password.
0:39:25	But if the TTL passes the threshold,
0:39:27	and the password is correct, then, I will allow the packet in."
0:39:33	But the key thing that's good about the BGP authentication
0:39:37	is since BGP is already running on top of TCP,
0:39:41	there's no need to define a separate BGP authentication.
0:39:45	You can just use the underlying option number 19, which is already part of TCP.
0:39:51	So, there's a lot of research that's been done on these type of attacks.
0:39:55	I believe one is, if you search for BGP reset attack, and I think it's called, Slipping the Window.
0:40:06	This is basically a proof of concept that someone did on its actually feasible to get this attack to work.
0:40:15	Based on some algorithm, they came up with to predict the TCP sequence numbers.
0:40:20	And they give the time that it takes to do that.
0:40:22	And in certain cases, you could have the atatcking application
0:40:27	figured out within 10 to 15 minutes or so with the values supposed to be and then the session drops.
0:40:34	So, ideally, you want the router to protect against these type of attack to begin with.
0:40:39	So, then you never have to worry about something like the TCP sequence numbers.
0:40:45	So, configuration wise, if we were to look at the command reference for BGP,
0:40:52	this is gonna be under the neighbor options.
0:40:56	Then it would be the neighbor...
0:41:00	Actually, the next one. Neighbor Timers through Show BGP,
0:41:04	Neighbor TTL Security.
0:41:10	So, the Neighbor TTL Security provides a light weight security mechanism for BGP.
0:41:16	To protect against utilization-based attacks.
0:41:20	Configuration wise, you specify for the neighbor what the minimum hop count should be
0:41:27	or actually the minimum TTL, what it should be when the packets come inbound.
0:41:33	So, example, if router 5 and router 6 is supposed to be two hops away,
0:41:37	then this is what the arguement is gonna be of the command.
0:41:41	So, it actually means, the reverse of that, they're gonna look for 255 minus those hops
0:41:46	to figure out if that particular sessionis valid.
0:41:50	Now, if you look at the specific user guidelines here,
0:41:52	it says that the TTL security and the EBGP multihop, these commands are mutually exclusive.
0:41:59	So, you do one or the other, not both of them at the same time.
0:42:03	But the key for this to work is that you have to do this on both sides.
0:42:07	So, if you're setting up a new BGP peering with your service provider,
0:42:12	it make sense to try to negotiate this capability with them.
0:42:17	So, even if they're only one hop away, even if the neighbors are directly connected,
0:42:21	it's still feasible that someone could do a TCP reset attack against the BGP router itself.
0:42:29	So, implementation-wise, this is really really simple,
0:42:31	if we were to go to router 6,
0:42:34	and let's do a trace route to figure out how do I get to the loopback of 5.
0:42:42	150.28.5.5
0:42:47	It says, "I either go to router 1 or to 4 and then to 5."
0:42:52	So, in either case, regardless of whether I'm going to 1 or 4, it's gonna be no more than two hops away.
0:42:58	Then likewise, on router 5, if I were to trace 150.28.6.6,
0:43:05	it say, "I could go to routers 1, 4 or the point-to-point link to 4, then I'm gonna go to 6."
0:43:13	So, there's multiple routes that are being equally load balanced between.
0:43:16	But as a whole, it's still no more than two hops away.
0:43:20	So, now, under the BGP process, I would say,"For this neighbor,
0:43:25	I don't want to have multihop." And actually, let's leave it on, let's see if it generates a log message.
0:43:31	We'll say TTL Security, the number of hops. There no more than two hops away.
0:43:37	Okay, and it does generate the error message there.
0:43:39	It says,"Remove EBGP Multihop before we TTL Security."
0:43:44	So, let's take this one off.
0:44:00	Then we'll do the same thing on router 6 side.
0:44:04	So, under BGP 6, No Neighbor 150.28.5.5 EBGP Multihop.
0:44:15	And instead, we want TTL Security and the number of hops, should be no more than two.
0:44:23	So, now, if we clear the BGP neighbor,
0:44:27	we should see that the session for router 5 goes down and then eventually, it comes back up.
0:44:32	If we look at the Show IP BGP Neighbor,
0:44:36	150.28.5.5, we should see now that it says
0:44:42	that the nighbor could be up to two hops away
0:44:47	but the minimum incoming TTL has to be no lower than 253.
0:44:55	because if they're two hops away, we know that they're using 255,
0:45:00	because that's the feature does to begin with.
0:45:02	So, 255 minus two hops away, it means that it should be no lower than 253.
0:45:07	So, if the packet comes in and it's 252, it's gonna be denied.
0:45:11	Now, we can actually test this if I were to go to router 6,
0:45:15	and let's say, I changed the path to get to router 5.
0:45:19	And we could just do this with a manual static route.
0:45:22	So, I say, To get to router 5's loopback,
0:45:25	I'm not gonna go towards
0:45:30	router 4 or 1.
0:45:34	So, normally, router 6 is going this way.
0:45:39	To 4 and then to 5 or to 1 and then to 5.
0:45:44	Let's say that I forced the traffic to re route in this direction.
0:45:48	So, now, it would be at least one to three hops away.
0:45:59	So, on router 6, we're gonna route this packet towards switch 1.
0:46:06	Then if we trace 150.28.5.5,
0:46:16	actually, now switch 1 is not agreeing on that.
0:46:19	So, instead of doing the static route,
0:46:24	I could change the EIGRP path selection.
0:46:27	So, let's say the delay on that Fast Ethernet link is really high.
0:46:32	Then we clear IP EIGRP neighbors.
0:46:38	So, ideally, router 6 should change its path selection so that we go to a different route.
0:46:44	And now, we could see it's three hops away.
0:46:47	So, on router 5, if we look at the Debug IP Packet Detail 100,
0:46:53	and Debug IP BGP,
0:46:56	then Clear the Neighbor,
0:46:58	Clear IP BGP 150.28.6.6,
0:47:14	And I'm not sure if it's gonna show a specific error message here.
0:47:26	It says, "Packet routing failed."
0:47:35	So, let's undebug this. Let's look at the Show IP BGP Summary now.
0:47:43	So, I think it's just silently discards the packet.
0:47:46	So, nothing is really changed in the configuration other than the route that we're using to get there.
0:47:50	So, we're still able to reach router 6 when the traffic is sourced from...
0:47:56	sourced from my loopback 0.
0:47:58	So, they are only two hops away from my perspective
0:48:01	but now when 6 does the trace to 5,
0:48:06	it's more than two hops away, so, now, this one is being denied.
0:48:13	So, the only disadvantage of this that if the remote device is actually more than two hops away,
0:48:19	sometimes it could be hard to predict what's the actual route that they're gonna use between them.
0:48:24	So, in a real design, it would be more realistic to use this type of feature between router 4 and router 5 directly.
0:48:33	So, even if there's only one path between them, it would still make sense to do it.
0:48:37	So, 4 and 5 are peering over this connected link.
0:48:41	They would say, the number of hops is one.
0:48:45	So, then, there's never a valid case where 5 would receive a packet spoofed from router 4's address.
0:48:52	It's trying to reset the session or it's trying to do some sort of update injection, for example.
0:49:05	But again, this is really gonna depend on whether that particular version that you're using is gonna support it.
0:49:11	So, if we look at this command, it says that this was...
0:49:15	integrated as of 12.3(7)T.
0:49:17	So, pretty much, any fairly recent version is gonna support this.
0:49:21	And this would then be the better design choice to use.
0:49:25	Instead of EBGP multihop, you would wanna use the neighbor TTL Security.

Now Viewing

CCIE R&S Advanced Technologies Class v4.5
Title:	CCIE R&S Advanced Technologies Class v4.5
Duration:	81h 42m
The CCIE Routing & Switching Advanced Technologies Class is the first step in understanding CCIE level technologies and is a companion to the Advanced Technologies Lab Workbook. Each technology you need to know for the CCIE Routing & Switching lab will be described in detail using an instructor led hands on demonstration. The class consists of over 80 hours of in depth explanations and examples.
Get instant access to our entire library!
	Sign Up
Download this Course
$299.00	Add to Cart

Establishing BGP Peerings, EBGP Multihop, BGP...

Create Bookmark