[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference irocz::common_brouters

Title:	Digital Brouters Conference
Notice:	New common-code brouter family: RouteAbout, DECswitch 900
Moderator:	MARVIN::HARTLL

Created:	Mon Jul 17 1995
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	929
Total number of notes:	3736

800.0. "Any experience with BGP??" by STKHLM::WEBJORN () Thu Mar 13 1997 10:32

    
    I have some anomalities using BGP with a DS900EF + RouteAbout MP SW.
    
    
    1.
    
    I have defined BGP speaker and 8 neighbors. I have a receive policy
    that accepts 'everything'.
    
    Originate policy:
    
    192.121.118.0 255.255.255.0 inclusive range
    192.121.119.0 255.255.255.0 inclusive range
    195.54.128.0 255.255.255.192 inclusive range
    
    
    Send policy:
    
    192.121.118.0 255.255.255.0 inclusive range
    192.121.119.0 255.255.255.0 inclusive range
    195.54.128.0 255.255.255.192 inclusive range
    
    
    
    	When looking with BGP monitor 
    
    dest ad 194.68.128.34		( neighbor AS router )
    
    I see only
    
    
    192.121.118.0
    195.54.128.0
    
    (192.121.119 is not presented as advertised. I'm not sure how to find
    out what is ACTUALLY sent, cept calling the other telcos and ask the 
    to look in their routers)
    
    Also, BGP seems to have a problem with lower than C masks.
    I had to cheat and send/originate with 255.255.255.0.
    
    Keeping the mask at .192, the route was not advertised.
    
    Gullik

T.R	Title	User	Date	Lines
800.1		MARVIN::PATEL	`Fri Mar 14 1997 07:52`	11
	What version of the software are you running ? If you are running V2.0 then you can DTF to trace the packets ( you will need to trace the output interface and filter IP packets and search for BGP - although the BGP analysis is there in DTF, there are no BGP tracepoints yet). Also check what BGP events are being logged - you can either do this by enabling the BGP events at the console or tracing the ELS tracepoint using DTF). Can you dump the IP routing tables and post them here ? This is to make sure all the routes you expect in BGP are actually in the routing tables. As for the masks I am not aware of any problems with extending it beyond 24 bits. I think you will need to submit a CLD ( if it is a customer problem ) or a PTR for the problem to be investigated.
800.2	.1 reformatted for the width-impaired (like me)	MARVIN::CLEVELAND	`Fri Mar 14 1997 09:01`	16
	<<< Note 800.1 by MARVIN::PATEL >>> What version of the software are you running ? If you are running V2.0 then you can DTF to trace the packets ( you will need to trace the output interface and filter IP packets and search for BGP - although the BGP analysis is there in DTF, there are no BGP tracepoints yet). Also check what BGP events are being logged - you can either do this by enabling the BGP events at the console or tracing the ELS tracepoint using DTF). Can you dump the IP routing tables and post them here ? This is to make sure all the routes you expect in BGP are actually in the routing tables. As for the masks I am not aware of any problems with extending it beyond 24 bits. I think you will need to submit a CLD ( if it is a customer problem ) or a PTR for the problem to be investigated.
800.3	4 net's only 3 announced.	STKHLM::WEBJORN	`Fri Mar 14 1997 14:34`	31
	I have upgraded the DecSwitch to 2.0.2. That cured the problem with not sending subnet mask 192. It now says it announces that net with mask FFFFFFC0. My ori and send rules say the same. However, I have 5 nets on the box. On e net is the BGP backbone (Gigaswitch) and that net is not announced. The other four nets are 192.121.118.0 255.255.255.0 192.121.119.0 255.255.255.0 192.121.126.0 255.255.255.0 195.54.128.0 255.255.255.192 the net 192.121.126.0 255.255.255.0 is not displayed as announced. locally I can ping 192.121.126.253 which is the router I/F.(from the other nets) so it's UP. It's such a simple config...?? Gullik
800.4	Bug is in way BGP destinations are displayed	MARVIN::PATEL	`Fri Mar 21 1997 12:35`	7
	After several mail exchanges with Gullik regarding this note, here is the final result. The bug is in the way the destinations for a neighbor are displayed. When walking the binary tree of routes, the code starts at sequence 1 instead of sequence 0 and hence always misses out 1 route in the display. There is no problem with the actual exchange of routes between the BGP neighbors.