[c-nsp] Can not establish MP-BGP sessions

Andy Saykao andy.saykao at staff.netspace.net.au
Mon Nov 16 17:48:04 EST 2009


P1=7301 and the other end P2=7606.
The PE's are 7301 running  12.2(31)SB13
 
Odd thing is that it was all working prior to switching across this our
new switched ethernet circuit.

________________________________

From: Aaron [mailto:dudepron at gmail.com] 
Sent: Tuesday, 17 November 2009 3:10 AM
To: Andy Saykao
Cc: Alex; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Can not establish MP-BGP sessions


What is the HW on both ends? Possible one has a bug that is causing
headaches.


On Mon, Nov 16, 2009 at 08:51, Andy Saykao
<andy.saykao at staff.netspace.net.au> wrote:


	Hi Alex,
	
	1/ When "mpls ip" is ON on both Gi4/0/1 and Gi0/2 - I can not
ping from
	PE2 > PE1 BUT I can ping from PE1 > PE2. That's my real problem
why
	MP-BGP won't come up bc I don't seem to have two way comms bt PE
	routers' BGP update-source lo99 address.
	
	POP1 [PE1 (lo99:172.16.99.13) --> P1 ] --switched ethernet-->
POP2 [P2
	
	--> PE2 (lo99:172.16.99.4)]
	
	
	Eg: Ping PE1 > PE2 (OK!)
	PE1#ping 172.16.99.4
	Type escape sequence to abort.
	Sending 5, 100-byte ICMP Echos to 172.16.99.4, timeout is 2
seconds:
	!!!!!
	Success rate is 100 percent (5/5), round-trip min/avg/max =
8/9/12 ms
	
	Eg: Ping PE2 > PE1 (NOT OK!)
	PE2#ping 172.16.99.13
	Type escape sequence to abort.
	Sending 5, 100-byte ICMP Echos to 172.16.99.13, timeout is 2
seconds:
	.....
	Success rate is 0 percent (0/5)
	
	Ping PE2 > P1 (OK!)
	Ping P2 > P1 (OK!)
	
	*** Seems like I can't get any traffic/labels beyond P1 to get
to
	PE1.***
	
	Forwarding table entry for PE1(lo99) looks ok on P1.
	
	P1#sh mpls forwarding-table 172.16.99.13 32
	Local  Outgoing      Prefix            Bytes Label   Outgoing
Next Hop
	Label  Label or VC   or Tunnel Id      Switched      interface
	8668   Pop Label     172.16.99.13/32   158269119     Gi0/0.152
	203.17.102.113
	
	2/ When "mpls ip" is ON on both Gi4/0/1 and Gi0/2 - BGP does not
come
	up.
	
	PE1#sh ip bgp vpnv4 all summary
	BGP router identifier 203.17.101.20, local AS number 4854
	BGP table version is 11983, main routing table version 11983
	15 network entries using 2115 bytes of memory
	15 path entries using 1020 bytes of memory
	6/3 BGP path/bestpath attribute entries using 840 bytes of
memory
	2 BGP rrinfo entries using 48 bytes of memory
	1 BGP AS-PATH entries using 24 bytes of memory
	1 BGP community entries using 24 bytes of memory
	2 BGP extended community entries using 48 bytes of memory
	0 BGP route-map cache entries using 0 bytes of memory
	0 BGP filter-list cache entries using 0 bytes of memory
	BGP using 4119 total bytes of memory
	BGP activity 1539/1500 prefixes, 6326/6263 paths, scan interval
15 secs
	
	Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ
Up/Down
	State/PfxRcd
	172.16.99.4     4  4854  147048  148587        0    0    0
06:48:13
	Active
	172.16.99.5     4  4854  147196  148642        0    0    0
06:48:08
	Active
	172.16.99.7     4  4854  147468  148593        0    0    0
06:48:16
	Active
	172.16.99.9     4  4854  146473  148502        0    0    0
06:48:01
	Active
	172.16.99.14    4  4854  147066  149123    11983    0    0
10:43:13
	7
	172.16.99.16    4  4854  146464  148574        0    0    0
06:47:52
	Active
	172.16.99.19    4  4854  149509  151673    11983    0    0
10:43:59
	5
	172.16.99.20    4  4854  149448  151672    11983    0    0
10:43:58
	2
	
	If I disable "mpls ip" on either Gi4/0/1 and Gi0/2, BGP does
come up but
	ofcourse I have no mpls vpn traffic because those links no are
no longer
	mpls enabled.
	
	Note that all Active BGP peers are PE devices which sit on the
POP2
	side. So all BGP peers on POP1 can establish BGP sessions with
each
	other but not to BGP peers at POP2. Like wise PE's at POP2 can
establish
	BGP sessions with each other and not with PE's located at POP1.
	
	The forwarding table from PE2 > P2 > P1 looks ok - so not sure
why you
	can't ping PE2 > PE1.
	
	PE2#sh mpls forwarding-table 172.16.99.13 32
	Local  Outgoing      Prefix            Bytes Label   Outgoing
Next Hop
	Label  Label or VC   or Tunnel Id      Switched      interface
	617    3034          172.16.99.13/32   0             Gi0/0.11
	203.10.110.211
	
	P2#sh mpls forwarding-table 172.16.99.13 32
	Local  Outgoing      Prefix            Bytes Label   Outgoing
Next Hop
	Label  Label or VC   or Tunnel Id      Switched      interface
	3034   8668          172.16.99.13/32   1582342       Gi4/0/1
	203.17.96.97
	
	P1#sh mpls forwarding-table 172.16.99.13 32
	Local  Outgoing      Prefix            Bytes Label   Outgoing
Next Hop
	Label  Label or VC   or Tunnel Id      Switched      interface
	8668   Pop Label     172.16.99.13/32   158253163     Gi0/0.152
	203.17.102.113
	
	The fact that PE's at POP2 can not communicate with PE's at POP1
is why
	I think  BGP isn't coming up between PE1 and PE2. I don't know
why mpls
	traffic/labels are not being swapped and forwarded beyond P1 to
reach
	PE1. MPLS config, ldp, mpls forwarding table and bindings all
look ok to
	me - any ideas??? Like I said we haven't changed any config
except
	moving from our existing circuit to a new protected switched
ethernet
	circuit.
	
	Thanks.
	
	Andy
	




	-----Original Message-----
	From: Alex [mailto:ecralar at hotmail.com]
	Sent: Monday, 16 November 2009 5:52 PM
	To: Andy Saykao; cisco-nsp at puck.nether.net
	Subject: Re: [c-nsp] Can not establish MP-BGP sessions
	
	Hi Andy,
	Couple of questions:
	1/ Can you ping between PE1 and PE2 _loopbacks_ across the
circuit when
	"mpls ip" is ON on both Gi4/0/1 and Gi0/2?
	2/ Can you establish BGP session between _interface_ addresses
when
	"mpls ip" is ON on both Gi4/0/1 and Gi0/2?
	Rgds
	Alex
	
	--------------------------------------------------
	From: "Andy Saykao" <andy.saykao at staff.netspace.net.au>
	Date: 16 November 2009 04:31
	To: <cisco-nsp at puck.nether.net>
	Subject: [c-nsp] Can not establish MP-BGP sessions
	
	> Hi All,
	>
	> We migrated a link between two pops onto a Switched Ethernet
circuit
	> and since then we can't pass MPLS VPN traffic between those
two pops
	> from
	> PE1 to PE2 because PE1 and PE2 can not establish a MP-BGP
session.
	>
	> -------------------------
	> BGP log on PE1:
	> -------------------------
	> Nov 16 14:26:48.693 AEDT: %BGP-5-ADJCHANGE: neighbor
172.16.99.4 Down
	> BGP Notification sent Nov 16 14:26:48.693 AEDT:
%BGP-3-NOTIFICATION:
	> sent to neighbor
	> 172.16.99.4 4/0 (hold time expired) 0 bytes
	>
	> -------------------------
	> Topology:
	> -------------------------
	> POP1 [PE1 (lo99:172.16.99.13) --- Switched Ethernet --> P1 ]
-->  POP2
	> [P2 --> PE2 (lo99:172.16.99.4)]
	>
	> -------------------------
	> P1:
	> -------------------------
	> interface GigabitEthernet4/0/1
	> description Connection to P2
	> bandwidth 150000
	> ip address 203.17.96.x 255.255.255.252 load-interval 30
negotiation
	> auto mpls ip
	>
	> -------------------------
	> P2:
	> -------------------------
	> interface GigabitEthernet0/2
	> description Connection to P1
	> bandwidth 150000
	> ip address 203.17.96.x 255.255.255.252 load-interval 30
media-type
	> gbic speed auto duplex auto negotiation auto mpls ip
	>
	> Interesting thing to note is that if I remove "mpls ip" from
P1's
	> interface, the MP-BGP sessions are formed between PE1 and PE2
and stay
	
	> up. When I put "mpls ip" back on the interface, the MP-BGP
session
	> times out with the error messgage in the BGP log above.
	>
	> The only thing that has changed is the introduction of the new
	> Switched Ethernet circuit. I was thinking that it might have
something
	
	> to do with jumbo frames but our UpStream Providers tells me
that they
	> have configured jumbo frames on either end of the link plus I
can ping
	
	> end from P1 to P2 with  byte sizes larger than 8000 bytes.
	>
	> Has anyone got any ideas as to why the MP-BGP sessions all of
a sudden
	
	> can no longer stay up and what further debug/troubleshooting i
can do?
	>
	> Thanks.
	>
	> Andy
	>
	> This email and any files transmitted with it are confidential
and
	> intended solely for the use of the individual or entity to
whom they
	are addressed.
	> Please notify the sender immediately by email if you have
received
	> this email by mistake and delete this email from your system.
Please
	> note that any views or opinions presented in this email are
solely
	> those of the author and do not necessarily represent those of
the
	organisation.
	> Finally, the recipient should check this email and any
attachments for
	
	> the presence of viruses. The organisation accepts no liability
for any
	
	> damage caused by any virus transmitted by this email.
	>
	> _______________________________________________
	> cisco-nsp mailing list  cisco-nsp at puck.nether.net
	> https://puck.nether.net/mailman/listinfo/cisco-nsp
	> archive at http://puck.nether.net/pipermail/cisco-nsp/
	>
	
	
	
______________________________________________________________________
	This email has been scanned by the MessageLabs Email Security
System.
	For more information please visit
http://www.messagelabs.com/email
	
	
______________________________________________________________________
	_______________________________________________
	cisco-nsp mailing list  cisco-nsp at puck.nether.net
	https://puck.nether.net/mailman/listinfo/cisco-nsp
	archive at http://puck.nether.net/pipermail/cisco-nsp/
	



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________



More information about the cisco-nsp mailing list