[c-nsp] MED on vpnv4 routes

Thu Aug 12 10:53:37 EDT 2004

Hmm, strange, I just tested in my lab w/ 27S2, and I receive the MED
just fine.. 

00:02:25: BGP(2): 195.253.0.114 send UPDATE (format)
6509:1002:40.0.0.1/32, next 10.253.0.104, metric 55, path , extended
community RT:6509:1002 RT:6544:2002

received as

00:02:25: BGP(2): 10.253.0.104 rcvd 6509:1002:40.0.0.1/32
00:02:25: BGP(2): 10.253.0.104 rcvd UPDATE w/ attr: nexthop
10.253.0.104, origin ?, metric 55, path 6509, extended community
RT:6509:1000 RT:6544:2000

ASBR3#sh ip bgp vpnv4 all 40.0.0.1
BGP routing table entry for 6509:1002:40.0.0.1/32, version 7
Paths: (1 available, best #1, no table)
  Advertised to update-groups:
     1         
  6509
    10.253.0.104 from 10.253.0.104 (10.253.0.104)
      Origin incomplete, metric 55, localpref 100, valid, external, best
      Extended Community: RT:6509:1002 RT:6544:2002
ASBR3#

In my test, I just put an outbound route-map at the external vpnv4
neighbor.. 

noticing that you import the route, I also tested a local vrf import at
the ASBR (in the example above, the ASBR3 has no vrfs configured, so it
doesn't import it). I configured a local vrf and imported the RT, and
the metric is there as well:

ASBR3#sh ip route vrf test
[...]
     40.0.0.0/32 is subnetted, 2 subnets
B       40.0.0.1 [20/55] via 10.253.0.104, 00:00:11
[...]

strange... can you open the case so TAC can take a closer look at this?

	oli

Timothy.Hall at alltel.com <> wrote on Thursday, August 12, 2004 3:31 PM:

> Here is the debug output for the GSR (sender):
> 
> *Aug 12 11:41:09.418: %BGP-5-ADJCHANGE: neighbor 10.0.200.2 Up
> r19#
> *Aug 12 11:41:09.418: BGP(2): 10.0.200.2 send UPDATE (format)
> 192.168.0.22:1:10.0.133.0/30, next 10.0.200.1, metric 50, path ,
> extended community RT:65001:1  
> *Aug 12 11:41:09.418: BGP(2): 10.0.200.2 send UPDATE (format)
> 192.168.0.6:1:10.0.136.0/30, next 10.0.200.1, metric 100, path ,
> extended community RT:65001:1  
> 
> Here is the debug output for the 7200 (receiver):
> 
> w0d: BGP: Import walker start version 1, end version 3
> 1w0d: BGP: ... start import cfg version = 2
> 1w0d: BGP: Prefix 192.168.0.6:1:10.0.136.0/30 to be imported as
> 0:0:10.0.136.0/30 -- Permitted 
> nexthop 10.0.200.1, origin i, path 65001, extended community
> RT:65001:1 1w0d: Path added
> 1w0d: BGP: Prefix 192.168.0.22:1:10.0.133.0/30 to be imported as
> 0:0:10.0.133.0/30 -- Permitted 
> nexthop 10.0.200.1, origin ?, path 65001, extended community
> RT:65001:1 1w0d: Path added
> 1w0d: BGP(2): Revise route installing 1 of 1 route for 10.0.133.0/30
> -> 10.0.200.1 to test IP table 1w0d: BGP(2): Revise route installing
> 1 of 1 route for 10.0.136.0/30 -> 10.0.200.1 to test IP table 
> 
> Last, here is the sh ip bgp vpnv4 * output:
> 
> Network          Next Hop            Metric LocPrf Weight Path
> Route Distinguisher: 0:0
> *> 10.0.133.0/30    10.0.200.1                             0 65001 ?
> *> 10.0.136.0/30    10.0.200.1                             0 65001 i
> 
> As you can see, metric appears to be sent, but not received???
> 
> tim
> 
> 
> 
> At 04:20 PM 8/11/2004 -0500, Timothy.Hall at alltel.com wrote:
>> We are having a problem with some lab testing. We set up two AS's
>> doing interprovider VPN, each AS has two ASBR's. The ASBR's are set
>> up with ebgp advertising only the vpnv4 routes. We set the MED for
>> the routes so that 
>> we would know which inter-AS link traffic would take. One border
>> router is an M-series, the other is a GSR. Problem is the GSR is not
>> sending the vpn routes with the MED set. The debug ip bgp update
>> output shows that the MED is set and the router thinks it is
>> advertising properly, however the other side does not indicate that
>> it is receiving the MED attribute. Also, it doesn'ty matter whether
>> the receiving router is an M-series or a Cisco router. Problem
>> occurs in both cases. 
> 
> Please provide the debugs from sender and receiver for any one of the
> prefixes in question.
> 
> Zaheer
> 
> 
>> GSR is running 12.0(27)S2.
>> 
>> Anyone have any ideas?
>> 
>> Thanks,
>> Tim
>> 
>>
************************************************************************
******************
>> The information contained in this message, including attachments,
>> may contain privileged or confidential information that is intended
>> to be delivered 
>> only to the
>> person identified above. If you are not the intended recipient, or
>> the person responsible for delivering this message to the intended
>> recipient, ALLTEL requests that you immediately notify the sender
>> and asks that you do not read the message or its attachments, and
>> that you delete them without copying or sending them to anyone else. 
>> 
>> 
>> _______________________________________________
>> 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/
> 
>
************************************************************************
******************
> The information contained in this message, including attachments, may
> contain 
> privileged or confidential information that is intended to be
> delivered only to the 
> person identified above. If you are not the intended recipient, or
> the person 
> responsible for delivering this message to the intended recipient,
> ALLTEL requests 
> that you immediately notify the sender and asks that you do not read
> the message or its 
> attachments, and that you delete them without copying or sending them
> to anyone else. 
> 
> 
> _______________________________________________
> 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/