weekend over. lab shut down. but I believe the couple of people who joined up learned a lot. one of the participants will be taking his CCIE lab this week. I'm waiting the good news.
Question came up. One of the participants was able to connect to be using a static default route. He sent me his configs. If that's what's on his router, so be it. However, I know from long hard experience that BGP does NOT form neighbor relationships with a neighbor the route to whom is NOT in the routing table. For example: R8#sh ip bgp 200.0.0.4 % Network not in table R8# as you can see, there is reachability and connectivity: R8#ping 200.0.0.4 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 200.0.0.4, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/80/128 ms R8# interestingly, the other side prints out a neighbor report, but indicated that no messages are being received or sent: R4#sh ip bgp nei 222.222.222.8 BGP neighbor is 222.222.222.8, remote AS 44001, external link BGP version 4, remote router ID 0.0.0.0 BGP state = Active Last read 02:42:47, hold time is 180, keepalive interval is 60 seconds Received 0 messages, 0 notifications, 0 in queue Sent 0 messages, 0 notifications, 0 in queue <<<======= no messages sent!!!!! Route refresh request: received 0, sent 0 Default minimum time between advertisement runs is 30 seconds For address family: IPv4 Unicast BGP table version 429, neighbor version 0 Index 3, Offset 0, Mask 0x8 0 accepted prefixes consume 0 bytes Prefix advertised 0, suppressed 0, withdrawn 0 Number of NLRIs in the update sent: max 0, min 0 Connections established 0; dropped 0 Last reset never External BGP neighbor may be up to 10 hops away. No active TCP connection R4# the guy who told me he is using static defaults is also using a dial up account to the internet. I am suspecting that concessions are made within the code to accommodate dial up. Anyone have any insight on this? Chuck Three operating systems for Tier One manufacturers under the sky Seven for the Tier Twos with their technology from the age of stone Nine for low end manufacturers doomed to go out of business One for Dark Box mounted on a Dark Rack In the land of the internet, where the networks all lie. One IOS to forward them all, one IOS to find them, One IOS to summarize them all and in the routing tables bind them In the land of the internet, where all networks lie JRR Chambers -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Chuck Larrieu Sent: Wednesday, November 07, 2001 10:52 AM To: [EMAIL PROTECTED] Subject: Open BGP Lab - across the net [7:25581] Over the past week or so I have been going through the Parkhurst BGP book in detail. As a result I have a fairly complex setup here in my home lab. So I would like to make my pod available for BGP research across the internet. You can connect your routers to mine using BGP across the net. I will have things set up beginning late Friday - after 7:00 p.m. Pacific Coast time ( Greenwich -8 ) If you would like to connect your routers to mine using BGP across the net, please contact me off line. I will be using AS #49191 for the connect point. my internal AS #'s are 1111, 5555, 9999, 60350, 60400, and 60670 When you contact me, I will need the public IP address of your router, and the AS number for peering. I will answer your e-mail with my own public IP address and the AS# Some things to remember when configuring: 1) there must be a route in your routing table to the IP address I provide. This can be a static route, but a default route or default network will not work 2) remember to use the eBGP multihop command. It does not hurt to use a value greater than 100. The peering establishment process can take a couple of minutes. 3) my connect point AS is in public space, but if my research is correct it is unassigned. Even if it were, there will be no effect on any public internet peering. connections must be configured correctly from both side. 4) I am assuming that people taking me up on this offer will not be using ISP or enterprise equipment to connect. I assume that all acceptors will be using private lab equipment. Do not put your company at risk for something like this study session, something that can be on the chaotic side. 5) people connecting from @home might want to double check their internet connections. I have had some problems connecting to @home users. I have also had some excellent sessions with @home users. 6) I suspect that there are some ISP's who filter BGP traffic. But for the most part, problems have been identified as misconfigurations. rest assured, I have done these sessions several times. It is interesting to do, and it gives me and other participants a chance to try different things based on being connected to an unknown source. Let's have some fun. Chuck Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=25894&t=25581 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
